heise online
  • c't
  • iX
  • Technology Review
  • Mac & i
  • mobil
  • Security
  • Netze
  • Open Source
  • Developer
  • c't-TV
  • Download
  • Telepolis
  • Resale
  • Foto
  • Autos
  • Preisvergleich
  • Stellenmarkt
  • Abo
  • weitere Angebote
    • Shop
    • Artikel-Archiv
    • Veranstaltungen
    • Whitepapers
    • heise-marktplatz
    • IT-Markt
    • Tarifrechner
    • Jobs bei Heise

c't Magazin
  • Startseite
  • Artikel
  • c't-Projekte
  • Hotline & FAQ
  • Treiber & mehr
  • Kolumnen
Software zu Projekten Allgemeine Hinweise
Archiv-Suche Newsletter RSS-FeedRSS

c't › c't-Projekte

c't-Lab
  • Login
  • Help/Guide
  • About Trac
  • Preferences
  • Wiki
  • Timeline
  • Roadmap
  • Browse Source
  • View Tickets
  • Search

Context Navigation

  • Start Page
  • Index
  • History
  • Last Change

Auto-Increment

Funktion in neuerer FPGA-Firmware, um größere Datenmengen in eine bereits laufende FPGA-Konfiguration zu bekommen, z.B. ROM-Inhalte von PicoBlaze- oder anderen Softcores oder arbiträre Wellenformen. Zu diesem Zweck wurden die SPI-Register 128 und 129 reserviert (änderbar über OPT 3- und AIR-Befehl). Kommuniziert mit dem ISE-Modul SPI_LC (wie "Load Core"), das problemlos parallel zu einem vorhandenen SPI-Modul ins FPGA eingebaut werden kann, da auf diese Register nur schreibend, nicht lesend zugegriffen wird.

Dateien auf der ins FPGA-Modul gesteckten SD-Karte mit den Endungen .MEM, .DAT und .DEC werden mit einem CFG-Aufruf (oder bei Auswahl mit dem Panel) automatisch auf eine bestimmte SPI-Adresse (Default 128, änderbar mit AIR=<SPI-Registernummer>) ausgegeben. Das SPI-Register 129 (immer eins höher als die Default-Vorgabe) erhält unmittelbar vor der Datei-Übertragung (und nur dann!) den mit AIS vorgegebenen Wert, etwa, um einen bestimmten von mehreren Cores/BlockRAMs zu selektieren (Defaultwert 0, zulässig 0 bis 255). Mit AIR=<SPI-Registernummer> kann der Dateitransfer (und nur dieser!) von .MEM, .DAT und .DEC-Files ins FPGA auf eine andere SPI-Adresse umgeleitet werden (sollte nur selten erforderlich sein und wird nicht empfohlen). Bitte beachten: AIR ist lediglich der Adress-Vorgabe-SubCh, AIS der Select-Vorgabe-SubCh für Dateiübertragungen, nicht zu verwechseln mit den eigentlichen Datenübertragungsregistern 128 und 129!

Siehe auch Beispiel ct-RAMloadDemo. Beispiel-Befehlsfolge (auch als LabScript):

// erstes BlockRAM, Binärdatei:
AIS=0 
CFG=SINUS.DAT
// jetzt ein PicoBlaze-Core:
AIS=1 
CFG=PBLAZE.MEM
// irgendwelche Daten ins dritte BlockRAM, Textdatei mit Dezimalzahlen:
AIS=2 
CFG=WERTE.DEC

MEM-Files sind Textdateien mit einer Hexadezimalzahl 8 bis 32 Bit pro Zeile. Sie können nicht nur zum Laden von PicoBlaze-Cores verwendet werden, sondern auch ganz allgemein zum Laden von Datenblöcken in FPGA-interne Datenstrukturen. Werden mehrere 2-KByte-BlockRAMs gekoppelt, sind auch längere Dateien als 1 KWorte zulässig.

Ab Version 2.31 der Firmware werden auch Textfiles mit dem Suffix .DEC angenommen, hier muss in jeder Zeile eine Dezimalzahl stehen , was den Export von Datensätzen z.B. aus Excel erleichtert. Die erste Zahl gelangt an Speicherstelle 0, die letzte Speicherstelle ist abhängig von der Länge der Datei (Anzahl der Zeilen, max. 1024 Werte bei einem 2KByte-BlockRAM mit 16 Bit Breite, jedoch eigentlich ohne Längenbeschränkung).

Der Aufbau der MEM- und DEC-Textdateien ist äußerst simpel. MEM-File-Beispiel (evt. vorhandene Meta-Zeilen mit "@" am Anfang werden ignoriert, stammen vom PicoBlaze-Assembler):

@0000000
00123
0AA55
000FF
2030A
...

Der PicoBlaze-Assembler liefert grundsätzlich 5 Hex-Ziffern pro Zeile (18-Bit-Instruktionen), die die Firmware in 32-Bit-Longwords umsetzt. Es ist jedoch jede beliebige Länge von 1 bis 8 Hex-Ziffern möglich. Die letzte Zeile muss wie alle anderen auch mit einem CR(+LF) abgeschlossen sein, weitere Leerzeilen sind unzulässig.

DAT-Dateien sind reine Binärfiles. Die einzuhaltende Little-Endian-Folge entspricht übrigens der des Atmel-Controllers: LSB first, d.h. aus der Datei-Bytefolge 55h, AAh wird am Ausgang eines 16-Bit-BlockRAMs mit 8-Bit-Eingang ("loadrom_in8") der Wert AA55h. Binärfiles werden vom FPGA-Controller übrigens deutlich schneller von SD-Karte geladen und übertragen als die zu interpretierenden Textdatei-Typen MEM und DEC. Auch ihre Länge sollte die des FPGA-internen BlockRAMs nicht überschreiten, sonst erfolgt ein Überlauf.

Bei DAT-Files kann man vor dem Laden auch mit dem Befehl AIW=<bytebreite> (AutoIncWidth, ab FW 2.32) vorgeben, wieviel aufeinanderfolgende Bytes zu einem Datenwort gehören, wenn es bei einem binären DAT-Load (und nur da!) das FPGA geschickt wird. Es sind die Argumente 1 (Byte), 2 (Word/Integer?) und 4 (Longword/LongInt?) zulässig. Einschalt-Default für AIW ist 4, womit im DAT-File immer 4 aufeinanderfolgende Bytes ein übertragenes Langwort bilden. MEM- und DEC-Files werden dagegen immer in 32 Bit Breite übertragen, die tatsächliche Nutzbreite hängt von der Länge der Hex- und Dezimalzahlen in der Texdatei ab (ungenutzte Bits bleiben "0").

// 16-Bit-BlockRAM mit DAT-File laden:
AIS=0 
AIW=4 // BlockRAM benutzt 16 Bit, aber 4 Bytes pro Wort im DAT-File
CFG=sinus16.dat

Alternative: Das Beispiel ct-RAMloadDemo verwendet als "loadrom_in8" ein Dualport-BlockRAM mit unterschiedlichen Wortbreiten (8 Bit Eingang, 16 Bit Ausgang), um es mit den Bytes eines DAT-Files mit der Wortbreite 1 Byte zu füllen. Hier ist dann vor dem Laden die Wortbreite mit AIW=1 auf 1 Byte einzustellen. Dieses Verfahren wird man allerdings nur dann wählen, wenn das DAT-File sehr umfangreich ist und man Übertragungszeit sparen möchte. 32-Bit-DATs eignen sich natürlich ebenso, um ein 8-Bit-RAM zu laden, sie verschwenden nur etwas Platz.

Die AutoIncrement-Register sind übrigens auch über die SubChannels 128 und 129 zugänglich (nur beschreiben, nicht lesen), sofern der Bock "SPI_LC" ins FPGA aufgenommen wurde. Dies kann man sich zu Nutze machen, um einen BlockRAM-Inhalt per LabScript zu erstellen. Das Beispiel erzeugt eine Art Sägezahn-Kurve:

ACC=0
REG 1=256 //willkürlicher Addierwert
REG 8=255 //Schleifenzähler
// Reset des AutoIncrement-Zählers, gleichz. CoreSelect 0:
VAL 129=0
LBL 1
OUT 128=0 // Wert von Akku (Reg. 0) ausgeben
ADD 1 // Addiere Reg. 1 zum Akku
DEC 8 // Decrement Schleifenzähler
BRG 1 // solange größer 0, springe zu Label 1
// Reset des AutoIncrement-Zählers, gleichz. CoreSelect 1:
VAL 129=1

Hier erfolgt wie bei allen SPI-SubCh 0 bis 63 immer eine Ausgabe in 32-Bit-Breite auf das AutoIncrement-Register 128. Aus diesem Grund wurde mit FW 2.33 die Standard-DAT-Wortbreite auch auf 4 Byte geändert (2.3 bis 2.32: 1 Byte), damit die FPGA-SPI-Konfiguration für direkte Script-Zugriffe nicht geändert werden muss.

Achtung: Diese absoluten SubCh-Nummern gelten nur, wenn im FPGA bei SPI_LC die Default-Adressen 128/129 verwendet werden. Wenn im FPGA eine andere Auto-Icrement-Registernummer zugeteilt ist, sollten diese unterhalb SubCh 63 liegen, damit sie per Script erreichbar bleibt. Nur die Adressen 128 und 129 sind von der Regel "SPI-Adressen nur bis 63 zugänglich" ausgenommen.

Zur bequemen Konvertierung von DEC- und MEM-Textfiles in Binärdateien habe ich meinen uralten Borland-Pascal-Compiler hervorgekramt und die Mini-Tool DEC2DAT.EXE und MEM2DAT.EXE erstellt (im Verzeichnis Utilities des Source-Browsers). Sie nehmen DECs und MEMs an und machen daraus ein DAT-File mit der geforderten 4-Byte-Breite pro Datenwort, natürlich in der passenden Little-Endian-Reihenfolge. Zu starten in der Eingabeaufforderung (geben dann auch die Zahl der gewandelten Zeilen und Bytes aus) oder durch Drag&Drop des umzuwandelnden DEC-/MEM-Files.

Anmerkung: Ein ähnlicher AutoIncrement-Mechanismus ist übrigens im QVGA-Interface auf den reservierten SPI-Registern 64 bis 72 realisiert, um BMPs schnell ins Video-RAM zu laden. Diese sind zwar ebenfalls über SubCh zugänglich, sollten aber nur dann benutzt werden, wenn man genau weiß, was man tut (Firmware-Sourcen studieren)!

Wie bei BMP-Files sind für DEC-, MEM- und DAT-Files Dateinamen unzulässig, die mit einer Ziffer beginnen.

Download in other formats:

  • Plain Text

Trac Powered

Powered by Trac 0.11.7
By Edgewall Software.

http://www.ctmagazin.de/
http://www.ctmagazin.de/projekte/

  • Datenschutzhinweis
  • Impressum
  • Kritik, Anregungen bitte an c't-WWW
  • Mediadaten
  • Copyright © 2011 Heise Zeitschriften Verlag
  • International: The H, The H Security, The H Open Source