Hallo allerseits,
ich steh' schon immer mit IMPACT auf'm Kriegsfuss...
Also, ich habe hier ISE12.3 unter Ubuntu 10.04 32bit sowie ein Digilent
Atlys board.
Ein .bit file habe ich, kann es auch sowohl mit IMPACT als auch mit
'djtgcfg' von Digilent/Adept auf das FPGA (Spartan6) laden (Digilent
plug-in fuer Linux/Adept funktioniert).
Auf dem Atlys ist ein N25Q12-SF (laut Schaltplan) Flash, fuer mich sieht
das wie ein 16MByte/128KBit mit SPI x4 aus.
Wie zum Geier kriege ich jetzt aus meinem .bit ein .mcs? Am besten nicht
mit IMPACT GUI Eintraegen sondern als 'promgen' Zauberzeile aus der
Shell...
Ich hab' da jetzt schon ein/zwei Stunden mit IMPACT rumgemacht, aber
datt klappt nicht so wie ich will...
Das geht mit Promgen ziemlich einfach. Schau mal in den PromGen User
Guide: zum Beispiel http://www.xilinx.com/itp/xilinx8/de/dev/promgen.pdf
(Da hat sich über die Jahre nicht viel geändert). Wichtig ist eigentlich
erst mal nur die Angabe des Inputfiles, die Promgröße (in kiByte, also
16384 bei dir) und das Ausgabe-Format. Bei MCS kann man das auch
weglassen.
Bei dir wäre also
1
promgen -n bitfile.bit -s 16384 -p mcs -u 0
wahrscheinlich schon ausreichend. Programmieren dann mit impact im batch
modus. Dazu kannst du eine cmd Datei erstellen und impact -batch
command.cmd aufrufen.
Configuration File '/video/fpga/vhdl/vhdl_projects/bithound/Project/FPGA/Binary/LATop_fw.mcs' does not have the data correctly formatted for SPI Configuration, As per the Preference setting the Byte Swapping will be automatically performed.
Hmm...da stimmt was mit der Verbindung auf dem Board nicht. Vielleicht
noch irgendwelche Jumper? Oder ein falscher Typ eingestellt? Vielleicht
ist der Flash ja nur x1 angeschlossen, das geht ja bei den x4 Dingern
auch. Zumindest ist das auf dem SP601 Board so gemacht, wenn ich das
recht in Erinnerung habe. Wie das mit dem Bit-Swapping für SPI war, kann
ich jetzt ausm Kopf nicht sagen, bin erst Ende September wieder auf
Arbeit. Eventuell beim promgen einfach mit der -spi Option noch dran
(-spi Disables bit swapping for compatibility with SPI flash devices.)
-spi habe ich probiert, keine Aenderung. Auch mit x1 und x4 probieren
bringt nix. Er kann nicht auf das Flash zugreifen, es kommt immer: SPI
device not found...
Bzgl. Jumper habe ich im Atlys-RM auch nix gefunden.
Und unabhaengig vom promgen-output (das .mcs), eine ID zuruecklesen oder
einen Blankcheck muss ja auch mit 'falschem' .mcs gehen. Muss mal
Digilent anmailen und evtl. mal nach den Versionen bei Digilents Adept
plugin nachsehen...
so, jetzt scheint er was zu tun...
Aenderungen: Ich hab' den M1 Mode-Jumper gesteckt, obwohl das laut
Atlys-RM nur beim booten des FPGA eine Rolle spielen sollte. Ausserdem
habe ich IMPACT mal von ISE aus gestartet. Scheinbar konnte er das Flash
loeschen (ID-check war wohl ok) und programmiert jetzt seit ca. 15
Minuten, ist jetzt gerade bei 9%.
Ich probier mal noch rum, wenn's mal funktionieren sollte stelle ich
mein Vorgehen einfach hier rein (wer weiss, wann ich's wieder
brauche...)
So, es laeuft jetzt stabil!
Ich schreib's mal hier runter, vielleicht ist es ja fuer jemanden
nuetzlich...
Wie geht das also?
* Digilent Atlys Board
* Ubuntu 10.04
* Xilinx ISE 12.3
* Digilent Plug-In fuer Linux (Achtung: Der USB Proempel tut bei mir nur
am USB-Mainboardanschluss, nicht an einer Frontblende/Hub!)
Das Atlys hat ein SPI Flash Chip um die FPGA Konfiguration zu speichern.
Will man das Flash programmieren, dann laedt IMPACT einen speziellen
FPGA Design ins FPGA, ueber diese Logik wird das per SPI angeschlossene
Flash programmiert.
Einen vorhandenen Design (.bit-file) flasht man folgendermassen in das
Atlys Flash:
* 'source /opt/Xilinx/.../settings.sh' # Setzt Environment fuer Xilinx
* 'cd /pfad_zu_dem_bitfile'
* 'which promgen' sollte sowas wie
/opt/Xilinx/12.3/ISE_DS/ISE/bin/lin/promgen anzeigen
* 'promgen -u 0 bitfile.bit -s 16384 -p mcs -spi' # erzeugt ein .mcs
file fuer das auf dem Atlys verwendete Numonyx SPI Flash (x4) mit
16MBytes
* 'impact &' # startet IMPACT
- Create a new project # Wenn noch keines existiert dann halt ein
neues
- Configure devices using Boundary-Scan # der Default
- Fehlermeldungen wg. dem windrv wegclicken
- Menue 'Output'->'Cable Setup' 'Cable-plugin' # digilent_plugin
auswaehlen
- Fenster rechts/oben: Maus Rechtsclick -> Initialize chain
- .bit file auswaehlen (fuer das FPGA)
- .mcs file auswaehlen (fuer das Flash/PROM)
+ SPI PROM, N25Q128, 1 auswaehlen # Das auf dem Atlys verbaute
Flash
Jetzt kann man spasseshalber mal das FPGA mit dem .bit file laden,
sollte alles funktionieren.
Selektieren des Flash, rechtsclick, Reading device contents sollte das
Flash auslesen, dauert einige Zeit (ca. 1 Minute)
Selektieren des Flash, rechtsclick, Program sollte das Flash dann
programmieren. Dauert bei mir ca. 1300 Sekunden, also ~20 Minuten. Ein
Verifiy dauert ca. 400 Sekunden, also ~7 Minuten.
Den Jumper JP11 (zwischen HOST-USB und UART Buchse) habe ich offen
gelassen. Beim allerersten flashen des Atlys hat es allerdings erst
funktioniert, als ich ihn geschlossen hatte (Grund: Keine Ahnung!). JP11
offen bedeutet laut Digilent Reference Manual: FPGA bootet vom Flash
ToDo: IMPACT per Shell starten, das GUI Geklicke geht mir auf den
Senkel!
Danke an Chris fuer die 'promgen' Tipps!
berndl schrieb:> ToDo: IMPACT per Shell starten, das GUI Geklicke geht mir auf den> Senkel!
Nichts leichter als das. Einfach eine command Datei mit etwa folgendem
Inhalt machen:
Christian R. schrieb:> Nichts leichter als das. Einfach eine command Datei mit etwa folgendem> Inhalt machen:> setmode -bscan> setcable -p auto> identify> attachflash -position 1 -spi "N25Q12..."> assignfiletoattachedflash -position 1 -file "progfile.mcs"> Program -p 1 -dataWidth 4 -spionly -e -v> quit>> Und dann "impact -batch commanddatei" starten.
ouch, du sprichst grosse Worte gelassen aus :o)
Ich muss mir den Impact Schrott mal reinpfeifen (bin da echt
unbeleckt...) und ich erwarte einfach mal, dass ich unter Linux da auch
noch auf ein paar Ungereimtheiten stossen werde. Aber erstmal tut ja
alles, der Rest sind die Feinheiten.
Danke fuer die Tipps!
- berndl
Hehe, keine Angst. Das schöne an der Xilinx Geschichte ist, dass es auf
Kommandozeilen-Ebene da meines Wissens keine Unterschied zwischen
Windows und Linux gibt. Ich hab noch nie eine extra Linux Behandlung
beim Aufruf der Tools gesehen, in den Dokus stehen immer nur die
Parameter allgemein drin. Für viele Sachen (gerade für PromGen und
iMPACT) nehme ich unter Windows auch gerne die Shell. Bis zum BitFile
tuts für mich der Klick auf "Implement Design". ;)
Übrigens, falls du den kompletten FPGA Designflow bis zum Bitfile als
command line brauchst, hier meine Bat-Datei, Übergabeparameter ist der
Projekt/Toplevename:
1
xst -ifn %1.xst && ngdbuild -aul %1.ngc && map -pr b -xe n -cm speed -ol high %1 && par -ol high -xe n -w %1.ncd %1.ncd %1.pcf && bitgen -d -g StartupClk:CClk -w -b %1 %1 %1.pcf
Die Verknüpfung mit &&, damit bei einem Fehler sofort abgebrochen wird.
Unter Linus müsste das ähnlich klappen. Voraussetzung ist natürlich ein
entsprechendes xst und prj File.
xc3sprog
svn co https://xc3sprog.svn.sourceforge.net/svnroot/xc3sprog xc3sprog
programmiert auch direkt aus dem .bit Bitfile. Fuer die SPI
Programmierung muss man ggf. noch ein passended bscan_spi Bitfile
erzeugen.
Christian R. schrieb:> Übrigens, falls du den kompletten FPGA Designflow bis zum Bitfile als> command line brauchst, hier meine Bat-Datei
Da hatte ich mal was gefunden, wie man aus ISE ein tcl script erzeugen
kann das dann von der shell/commandline aufgerufen werden kann. Hab' ich
aber nur im Gschaeft irgendwo rumliegen, muss ich die Woche mal
nachsehen.
@berndl (Gast):
Nein, der bscan_spi core ist anders als der Xilinx BSACN-SPI core.
Leider habe ich bei Xilinx keine Dokumentation zu Ihren BSCAN_SPI core
gefunden, deshalb habe ich den Core aus
http://code.google.com/p/xilprg-hunz/wiki/IsfAccesss
uebernommen.
Im bscan_spi Unterverzeichniss von xcs3prog gibt es fuer einige
Bausteine schon ein fertiges Bitfile, fall nich vorhanden muss man ein
passendes UCF File mit den Pinnummern der SPI leitungen machen und dann
das Bitfile bauen.
Ein Bitfile ist ein Bin-File mit zusaetzlichen Informationen. Siehe dazu
z.b. xc3sprog oder
http://www.fpga-faq.com/FAQ_Pages/0026_Tell_me_about_bit_files.htm
Die Synchronisationssequenz, zu der 0xAA 0x99 0x55 gehoert, gibt es auch
im Bitfile. Bei der Konfiguration sucht das FPGA im
Konfigurationsspeicher nach dieser Synchronisationssequenz, danach
kommen einige Befehle und dann der zu schreibende Inhalt für
konfigurationsspeicher.
Hi Uwe,
jetzt bist du ja ein Crack im Vergleich zu mir was das programmieren von
FPGAs angeht...
Also wie ich jetzt mit xc3sprog das Flash auf dem Atlys programmieren
soll ist mir echt schleierhaft... So wie ich das sehe muesste folgendes
passieren:
* Dummy Design ins FPGA laden damit das FPGA den SPI-Flash programmieren
kann
* Den echten Design nachschieben, das FPGA wuerde dann das Flash
proggen...
Ich bin da wirklich kein Spezl was diese Dinge angeht. Aber
Hinweise/Tipps werden jederzeit gerne genommen, ich versuche halt, unter
Linux einigermassen mit der Windows-lastigen Toolchain klar zu kommen...
Das indirekte Programmieren bei iMPACT läuft so, wie du vermutest. Ein
kleines Design (*.cor) übernimmt die Umsetzung der JTAG Befehle auf die
entsprechenden SPI Pins. Die indirekte Programmierung über xc3sprog
läuft wohl über den Boundary Scan Modus. Dazu wird mit den Boundary Scan
Instruktionen die SPI Funktionalität nachgebildet, ohne dass ein Design
auf dem FPGA läuft. Sowas machen wir bei der Produktion auch mit dem
Göpel System, ist aber wesentlich langsamer als die Xilinx Geschichte.
@Christian R.
Nein, auch xc3sprog laeuft ueber einen Core.
Wie gesagt, xc3sprog hat schon fuer einige Bausteine fertige
bscan_spi.bit Core, fuer alle anderen Baustein kann man den Core mit
wenigen Schritten selbst erzeugen. Nur das UCF File mit den SPI Pins
muss man noch schreiben.
Ja das klingt fuer mich plausibel...
Also, das .cor file wird in den FPGA geladen. D.h. der FPGA ist aktiv,
'schafft was'. Jetzt wird irgendwie ein weiteres .bit-file uebertragen
und der geladene .cor kann damit umgehen, d.h. das ganze in SPI
Kommandos fuer das Flash umsetzen.
Was da an IP/Knoff-hoff im .cor steckt: Ich hab' keine Ahnung. Aber das
ist doch der Schluessel um das Flash zu programmieren?!
Die IP/Knoff-hoff in bscan_spi ist im VHDL/Verilog Code oofengelegt. Und
damit auch die Schnittstelle fuer externe Programme um uber JTAG mit dem
SPI speicher zu sprechen.
Achso, ich dachte, es läuft über boundary scan. Das bscan im Core-Namen
hat mich da auf die falsche Fährte geführt.
@berndl: Naja, so in etwa. Das Cor File an sich ist ein lauffähiges FPGA
Design für genau diesen FPGA, was JTAG Kommandos (man kommt intern im
FPGA nämlich an die JTAG Kette heran) auf SPI umsetzt. Da ist nicht viel
Hexerei dabei. Also funktioniert XC3SProg nach dem gleichen Prinzip wie
impact. Da du ja ISE sowieso installiert hast, kannst du auch gleich
impact nutzen. In der Kommandozeile funktioniert das 1a, nicht so buggy
wie die GUI Version.
Mahlzeit,
ich habe mir den xc3sprog link mal angesehen. Ein .ucf existiert fuer
den S6 von mir/dem Atlys, allerdings passt das package des .bit nicht,
muss ich also ein eigenes bauen (Jetzt ist mir auch klar, wie das
funktioniert!). Das werde ich dann bei Gelegenheit mal ausprobieren.
@Chris: Designflow von der Shell/Command line geht auch so, wenn ein
.ise oder .xise exisiert:
* Project->Generate Tcl Script... (erzeugt ein .tcl mit dem Namen des
.ise/.xise)
* Das kann dann mit 'xtclsh filename.tcl rebuild_project' aus der Shell
gestartet werden.
Wenn man nur in existierenden Designfiles rummacht, kann man sich so den
ganzen ISE Overhead sparen. Im .twr file findet sich auch der statische
Timing Report.
Ja, die TCL Shell kenne ich auch, das funktioniert auch ziemlich gut.
Mit der komplett eigenständigen Lösung ist man etwas flexiber, macht
aber auch mehr Aufwand. Leider muss man in beiden Fällen, wenn man
Synthese- oder sonstige Optionen ändert, händisch nacharbeiten. Entweder
das TCL Script neu generieren oder die Optionen von Hand nachtragen. Die
ganz harten Jungs nehmen die Lösung ohne das Script, denn da muss man
nicht die ISE einmalig benutzen. Viel mehr nervt mich die Wehemenz, mit
der sich Xilinx seit Jahren gegen jegliche Art der Versionskontrolle
verweigert. Das ist komplett unverständlich und aus der Steinzeit.
Selbst nach einem Cleanup Project Files sind noch massenhaft
Müll-Dateien im Projektverzeichnis, so dass das SVN Einchecken ziemlich
nervig ist.
Christian R. schrieb:> Selbst nach einem Cleanup Project Files sind noch massenhaft> Müll-Dateien im Projektverzeichnis, so dass das SVN Einchecken ziemlich> nervig ist.
also ich habe nur die .vhd, .ucf, .xise, .do bei mir im SVN drin. Der
Muell auf meinem lokalen Laufwerk stoert mich nicht, beim commit gehen
nur die obigen Dateien ins Repository. Aber du hast recht, ISE ist schon
ziemlich chaotisch. Eigentlich hilft nur, die ganzen Designfiles zu
strukturieren (Directories), dann muss man nur noch mit dem .xise
aufpassen...
Zumindest das .xise ist um laengen besser als das alte .ise
Christian R. schrieb:> Viel mehr nervt mich die Wehemenz, mit> der sich Xilinx seit Jahren gegen jegliche Art der Versionskontrolle> verweigert.
Hehe. Irgendwann konnte man mit der ISE mal Snapshots erzeugen (=
Versionskotrolle für Excel-User, BWLer, younameit...)
> Das ist komplett unverständlich und aus der Steinzeit.
Nicht nur das :-(
Immerhin scheint die aktuellen Version Punkte im Pfadnamen richtig zu
verarbeiten.
> Selbst nach einem Cleanup Project Files sind noch massenhaft> Müll-Dateien im Projektverzeichnis, so dass das SVN Einchecken ziemlich> nervig ist.
Ich habe Quelltext und Projektdaten in verschiedenen Vereichnissen:
Auch mit Zeitstempeln steht ISE auf Kriegsfuss. Wenn man mit coregen aus
*.xco Dateien die noetigen Zwischendateien erzeugt, dann wird jedesmal
der Zeitstempel des *.xco File aktualisiert.
Dafuer hatte ich aber auch schon Situationen, dass z.B. der Syntaxcheck
durchgelaufen ist, das neue Ausgabefile aber gleich einem vorhandenen
File im Arbeitsverzeichnis gewesen waere und dann wurde kein Ausgabefile
mit neuen Zeitstempel erzeugt...
Mein makefile hat daher viele mv und touch Operationen...
Ich hab natürlich auch nur die relevanten Dateien im Repo, aber nervig
ist das ganze schon. Richtig ulkig ist, wenn man einen DCM als CoreGen
Projekt im ipcore_dir hat. Da wird nur das xaw gespeichert, bei der
Synthese wird das vhdl File aber im Projektverzeichnis erzeugt. Was das
soll, ist mir total schleierhaft. Naja, andere Toolchains haben andere
Macken. Immerhin schmiert die Kiste nicht mhr 3 mal am Tag ab, seit die
die xise xml Projekt-Files haben.
HALLO!
DAS PROBLEM MIT PROM DOWNLOAD HABE ICH MIT EIN USB STICK GELOEST:
1/ die .BIT Datei im Hauptverzeichniss von irgend ein U~SB Stick
2/ LINKS im USB HOST STECKER
3/ EINSCHALTEN MIT JP11 ZUGEDECKT
ES LADET DEN .BIT AUTOMATISCH!
GRUSS AN ALLEN
Hi,
Auch wenn der Thread schon weng alt ist. Könnten das doch noch
interessant sein:
1. Das mit dem JP11 ist echt interessant. Beim Auslieferungszustand
funktioniert das flashen über impact nicht. Wenn man aber den JP11
setzt, dann Strom an/aus, dann klappt flashen bis auf
1
INFO:iMPACT - '1': Flash was not programmed successfully.
Danach geht es auch mit getrenntem JP11.
2. Hier mal meine impact batch file
Thread beobachten
Seitenaufteilung abschalten