Ergänzungen und Berichtigungen FPGA

Bitte beachten Sie die Hinweise unter FirmwareFlashen zum Fuses-Block des ATmega644!

Wenn man AVR Studio verwendet, so ist die Fuse-Belegung nicht ganz klar. Bei mir geht es mit den Werten FE, DF, FE (extended...low). Wenn man falsche Fuse-Werte angibt, so funktioniert evtl. der Oszillator nicht mehr und man kann nicht weiter zugreifen. In diesem Fall hilft es, ein externes Clock-Signal an Pin XTAL1 einzuspeisen, z.B. die Clock des STK500 oder von einem Quarzoszillator (beliebige Frequenz 1 bis 16 MHz). Man erspart sich dadurch das Auslöten des 644er.

Absturz beim Einschieben einer Speicherkarte

Sollte das FPGA beim Wechseln (genauer: Einschieben) einer SD-Karte kurz "hängen", hilft ein Stützkondensator 470µ oder 1000µ/6V3 (möglichst Low-ESR-Typ) von der 3,3V-Leitung (Pluspol!) nach Masse. Dieser kann bequem auf dem Lochrasterfeld hinter der VGA-Buchse montiert werden, die 3,3V der VG-Leisten sind bis hierhin durchgeführt. Zusätzlich kann man noch den 100n-SMD direkt am Kartenslot durch einen 4µ7 oder 10µ SMD-Keramischen ersetzen (zuhauf in Grüppchen auf ausgemusterten PC-Mainboards nahe der CPU zu finden), dann sollten auch "unfähige" SD-Karten laufen. Und wenn man schon mal dabei ist: Ein paar davon statt der 100n-SMDs unter dem FPGA (Lötseite) schaden auch nicht.

Ein Leser berichtete von Problemen mit SD-Karten eines bestimmten Herstellers.

Korrumpiertes EEPROM

Ein korrumpiertes EEPROM kann bei Experimenten leider immer mal vorkommen, trotz Schreibschutz der wichtigsten Default-Parameter. Evt. funktioniert dann die Kommunikation FPGA <-> ATMEGA nicht (z.B. ct-BASIC lädt keine Programme mehr). Im Zeifelsfall die Kommunikationsregister-Inhalte (Syntax-Tabelle) überprüfen oder EEPROM gleich neu programmieren.

Bei älteren ATMEGAs können vor allem die ersten Bytes beim Absinken der Versorgungsspannung unabsichtlich überschrieben werden (die ich schon gar nicht mehr benutze, blockiert von "Dummy" im Sourcecode). Dies ist ein Hardware-Fehler in der CPU. Der ATmega644 sollte diesen Bug eigentlich nicht mehr haben. Werde trotzdem mal über eine EEPROM-Prüfsumme nachdenken.

Lötfehler am FPGA

Sollte sich merkwürdige Fehler ergeben (FPGA-Konfiguration lädt nicht, falsche Farbdarstellung, DAC-Ausgangsspannungen nicht monoton stetig, externes SRAM wird fehlerhaft geladen, ct-BASIC geht nicht etc.), können bei der Fertigung fehlerhaft gelötete FPGA-Pins (Zinnbrücken) schuld sein. Das ist leider auch bei meiner ersten von Segor gelieferten Platine so gewesen. Kontrollieren Sie als erstes die Betriebsspannungen des FPGA (3,3V, 2,5V und 1,2V), die etwa 5% abweichen dürfen.

Wenn das CORERAM- oder DACRAM-SRAM nicht einwandfrei ist, läuft natürlich auch der "6502" des ct-BASIC nicht an. Dann bleibt der initiale Testdaten-Inhalt der FPGA-internen BlockRAMs auf dem Bildschirm (die ASCII-Zeichen), weil sie niemals überschrieben werden. An sich schon mal ein gutes Zeichen, weil die FPGA-Konfiguration bis hier einwandfrei geklappt hat.

Im Zweifelsfall alle FPGA-Pins nachlöten: Satt mit 0,5er Lötzinn drüber, bis alle Pins einer Seite miteinander verbunden sind, dann mit Lötsauglitze alles wieder absaugen und mit 10x-Lupe kontrollieren. Mit bloßem Auge erkennt man nix, selbst eine Lupenleuchte vergrößert nicht stark genug! Hartnäckige Brücken kann man mit einem Cuttermesser freibekommen. Pastöses SMD-Flussmittel aus der Tube sollte, falls angewendet, entfernt werden, das aus dem Lötzinnseele ist nur bei der DIV-Platine störend.

Sonstiges

Die Größe einer Konfigurationsdatei für den XC3S400 beträgt 208 KByte und nicht, wie im Artikel angegeben, 2 MByte; so groß ist nur die Rawbits-Datei in ASCII-Darstellung.

Es wurde der zusätzliche Abfrage-Parameter FNM (SubCh 242, Anzahl der Dateien) eingeführt.

Beim Einschieben der Karte wird die mit OPT 30 festgelegte FPGA-Konfigurationsdatei oder ein INI-Script geladen (z.B. OPT 30=BASIC.INI oder OPT 30=MAIN.CFG).

Die LED_blinker.BIN-Konfiguration zum Test des FPGA und alle weiteren ISE-Projekte finden Sie im Repo-Browser unter  FPGA_ISE

Sie benötigen für eine Neusynthese und für eigene FPGA-Projekte das  WebPACK von Xilinx (2 GByte groß, benötigt u.U. mehrere Stunden zur Installation).

Eine neue SPI-Referenzimplementation finden Sie im Beispiel-Projekt ct-Ports, ebenfalls unter  FPGA_ISE zu finden. Von der ersten Version unterscheidet sie sich durch eine einstellbare Basisadresse (0 => 0, 1 => 16, 2 => 32 usw.) und Strobe-Ausgänge für jeden 32-Bit-Port. Gegenüber der in c't 4/2009 abgedruckten Fassung wurden einige platzsparende Vereinfachungen an der SPI-Implementation vorgenommen.

Achtung: 5V-Pegel können das FPGA beschädigen! Verwenden Sie hierfür immer einen 220R-Vorwiderstand, wenn Sie die FPGA-I/Os mit den Ausgängen von 5V-Schaltungen (TTL oder CMOS) verbinden wollen.

Hilfsmittel

Für die Entwicklung von schnellen FPGA-Applikationen unbedingt empfehlenswert ist ein Logik-Analysator mit mind. 100 MHz, besser mit 500 MHz Sample-Rate und 32 Kanälen. Ich verwende den sehr brauchbaren und dabei mit rund 300 Euro recht preiswerten LogicPort von  Intronix (kostenlose Demo verfügbar).

LabScript

Mit Version 1.0 der Firmware wurde eine Script-Möglichkeit (LabScript) eingeführt: Eine Text-Datei (Endung .INI) kann im File-Menü oder per Befehl ausgewählt und als Script ausgeführt werden. Die Befehlszeilen werden so interpretiert, als ob sie vom OptoBus bzw. PC kommen würden, und auch nur dann, wenn die mitgegebene Moduladresse mit der des FPGA-Moduls übereinstimmt. Somit ist es möglich, auch aufwendigere Parameter-Konstrukte oder ganze Datenblöcke in die SPI-Register des FPGA zu schreiben. Ebenso ist es möglich, über das Script Befehle/Abfragen? an andere c't-Lab-Module abzusetzen, dafür muss das FPGA-Modul aber das erste in der OptoBus-Kette sein.

Sollten die 64 zulässigen Register nicht ausreichen, empfehle ich, ein Register im FPGA mit AutoIncrement-Adressgenerierung zu implementieren (Achtung: Dieses darf nicht auf den Adressen 0 bis 3 liegen, da diese ständig für die Panel-Anzeige/Einstellung? aktualisiert/beschrieben werden). Im Script wird dann ständig dasselbe FPGA-Register beschrieben, dass wiederum die Adressen intern hochzählt. Praktisch, um z.B. Tabellen oder emulierte µC-Programme per Script in ein FPGA-RAM zu laden.

PicoBlaze-Support und DAT-Autoinkrement

Firmware 2.1 liest nun PicoBlaze-MEM-Files direkt von SD-Karte ein und schickt sie binär (18-Bit-Instruktionen) über vorbestimmte SPI-Adressen (Default: SubCh/SPI-Datenregister 128 mit AutoIncrement, Reset-Register 129) an ein Dual-Port-BlockRAM im FPGA. Um eine PicoBlaze-"Firmware" ins FPGA zu laden, genügt es nun, das vom PicoBlaze-Assembler KCPSM3.EXE (Befehlszeilen-Programm, Anwendung siehe pmake.bat) erzeugte .MEM-File auf die SD-Karte zu kopieren und mit dem FPGA-Modul-Bedienpanel diese Datei auszuwählen. Klick, und drin - nix mehr mit BMM und data2mem! Im FPGA müssen hierfür einige Vorkehrungen getroffen werden, siehe hierzu das ISE-Beispiel ct-PicoBlazeDemo. Die MEM-Datei kann natürlich auch ferngesteuert mit dem CFG-Befehl eingelesen werden, siehe hierzu die  aktualisierte Syntax-Tabelle.

Konfigurieren Sie das FPGA mit main.bit und rufen Sie dann mit dem Bedienpanel die PicoBlaze-Firmware PB_BLINK.MEM auf (ebenfalls auf die SD-Karte kopieren). Die LED neben dem FPGA sollte nun schnell blinken, angesteuert von einem Programm im PicoBlaze-Core (hier 100 MHz Takt).

Ein ähnlicher Mechanismus lädt binäre DAT-Files ins FPGA, hier wird allerdings nichts interpretiert, die Datei wird in Byte-Breite in das Auto-Inkrement-Datenregister geschrieben. Siehe hierzu auch unbedingt AutoIncrement im Wiki.

Nutzung der ADA-IO-Karten

CONN3 der FPGA-Platine ist für den Einsatz der ADA-IO-Karten AD16-8 und DA12-8 vorgesehen; die FPGA-Konfiguration ct-picoBlazeADA, die diese Karten ansteuert, ist inzwischen verfügbar. Sie unterstützt bislang allerdings nur die 16-Bit-Version der DA12-8 mit LTC1655.

Leider ist die VG-Leiste in zwei Punkten nicht ganz kompatibel zur ADA-IO (Design/Layoutfehler?):

PC5 der ADA-VG-Leiste liegt bei FPGA-Platine auf Masse, nicht auf einem IO-Pin. PC5 (nur benutzt als ENA vom DG408 auf DA16-8 Platine) ist deshalb auf PC1 (P90 beim FPGA-Modul) zu legen. Die Referenz-Jumper der ADA-IO-Karten dürfen nicht gesteckt sein, das FPGA kann mit der Referenzspannung nichts anfangen.

Pin 11a/b der VG-Leiste ist bei den ADA-IO-Karten AD16-8 und DA12-8 mit Masse verbunden. Bei Bestückung mit einer einreihigen VG-Messerleiste (nur Reihe a) können AD16-8 und DA12-8 auch auf CONN1 und CONN2 des FPGA-Moduls eingesetzt werden, wenn (!) man den Masse-Pin 11a auf der Steckkarte durchtrennt; sonst wird die 3,3V-Spannung des FPGA-Moduls kurzgeschlossen! Bei bereits bestückten AD16-8- und DA12-8-Karten, die auf CONN1 und CONN2 eingesetzt werden sollen, kneift man zweckmäßigerweise auch die komplette b-Reihe durch.

Aufgrund der gleichzeitig benutzen IO-Leitungen ist ein gleichzeitiger Einsatz von DACRAM- und einer der alten ADA-Karten nicht möglich.

Segor liefert jetzt eine ADA-FPGA-Riser-Karte, die diesen Fehler ausbügelt; hier können sogr mehrere ADA-IO-Karten eingesetzt werden.

Die über I2C gesteuerte IO32-8 kann bis auf weiteres nicht eingesetzt werden, obwohl die I2C-Implementierung auf dem FPGA theoretisch möglich ist. Sind sehr viele I/O-Ports gewünscht, sollten diese mit 4014- oder 4094-Schieberegistern implementiert werden.