Ich grüße euch!
ich bräuchte momentan echt mal Hilfe. Ise wird ja nicht mehr
weiterentwickelt und ich habe das Gefühl, dass das nicht mal eine runde
finale Version werden soll. Warum auch immer - die kleinen fpga und cpld
sind ja darauf angewiesen. Naja ist ja Sache von Xilinx.
Ich habe echt einiges in der Richtung gegoogelt, aber mein Problem
kriege ich nicht gelöst: ich habe daheim einen win10 64 bit Rechner. Ich
habe hier noch einen Win7 32bit Rechner zur Verfügung, worauf ise incl.
impact funktioniert. Daher weiß ich, dass es prinzipiell funktionieren
-müsste- ein Nexys2 Board mit Spartan3E 1200 zu flashen.
So wie ich es verstanden habe ist impact im batch mode auch unter den
modernen Windows Versionen zu benutzen. Deswegen habe ich mich letzte
Woche in windows batch eingearbeitet. So gut es geht.
Damit lässt sich aber nicht programmieren. Anscheinend wird die device
ID falsch ausgelesen. Stehe jetzt wirklich auf dem Schlauch und weiß
nicht mehr weiter. Welche Ursache könnte das haben? Es sieht ja so aus
als ob die id einfach geshiftet ist?!?
Was könnte ich tun?
Es handelt sich bei mir um einen chinesischen Clon des Xilinx platform
cable usb. Falls jemand da die Schuld sehen würde im batch mode, wäre
ein programmers wie
https://shop.trenz-electronic.de/de/TE0790-02-XMOD-FTDI-JTAG-Adapter-Xilinx-kompatibel
natürlich eine Idee. Nur ins Blaue halt nicht. Und auf dem windows7
Rechner funktinoiert es ja auch mit dem chinesischen aus ise heraus zu
programmieren.
Ich habe meine cmd files und den Fehlerscreenshot mal angehängt.
Vielleicht hilft das beim Fehler aufzeigen oder Leuten die Probleme mit
impact haben.
also ich habe probleme mit den batch Befehlen.
-addDevice scheint Probleme zu machen; ich habe assignfile genommen
echo setmode -bscan > impact_script.txt
echo setcable -p auto >>impact_script.txt
echo identify >>impact_script.txt
echo info >>impact_script.txt
echo assignfile -p 1 -file %~1% >>impact_script.txt
echo program -p 1 -prog >>impact_script.txt
echo closeCable >>impact_script.txt >>impact_script.txt
echo quit >>impact_script.txt
so sieht es ganz gut aus. :-)
füge ich aber noch ein -v zum program gibt es Ärger mit einem input-file
"top.msk" was fehlt.
Es ist ein bischen wie voodoo für mich. Kann mir da noch jemand was
Erklärendes zu sagen?
Steff schrieb:> so sieht es ganz gut aus. :-)
Wo genau ist das Problem?
Das '-v' heißt vermutlich 'verify' und regt impact an, den Bitstream vom
FPGA zurückzulesen. Damit das funktioniert muß bitgen noch eine
.msk-Datei erzeugen.
Das habe ich vor Jahren mal probiert und es ging irgendwie nicht so
richtig.
Braucht man aber eigentlich auch nicht, wenn man nur das FPGA per JTAG
lädt.
Um den SPI-Flash an einem Spartan 6 zu programmieren sieht meine
Steuerdatei so aus:
Wenn ich mich betr. Sp3e-1200 nicht irre und etwas Ketzerei erlaubt ist,
könnte man mit xc3sprog oder papilio-prog sehr viel mehr Spass haben als
mit dem grottigen Impact, und schneller ist es auch, allerdings kann ich
nur für die Linux-Seite/FTDI2232H-Adapter sprechen.
Vom Hersteller Digilent gibt es auch ein Tool:
http://store.digilentinc.com/digilent-adept-2-download-only/
Das kann vor allem .bit Dateien nicht nur direkt ins FPGA laden sondern
auch in das Flash auf dem Board ohne dass man eine .mcs Datei erzeugen
muss.
Das gibt es auch als Runtime für Linux das schön über die Kommandozeile
bedienbar ist.
Hi!
danke erst mal für die weiteren Meldungen.
Ich habe auch noch mal ein paar Stunden versenkt. Habe festgestellt,
dass das Problem war in Verbindung mit automatischer Initialisierung der
jtag Kette noch ein addDevice zu machen.
Einfach nur den Teilnehmern in der Kette per addFile das entsprechende
zuordnen.
Verify habe ich nachgelesen und...ja... brauche ich sicher auch nicht
;-)
Den Rest werde ich noch mal weiter verfolgen!
Etwas offtopic.
Aber bin ich eigentlich der Einzige der es extrem fragwürdig macht, was
Xilinx da praktiziert? Wundere mich, dass Xilinx von den Kunden nciht
etwas unter Druck gesetzt worden ist oder die das selber für nötig
befunden haben. Ich habe ja nichts dagegen, in Bezig auf neue
FPGA-Linien einen cut zu machen, aber dann entweder abwärts kompatibles
Vivado oder eben minmal Pflege...
Ich meine: die ise ist immerhin noch für aktive Produkte notwendig
(cpld) und man hält es nicht für nötig diese auf aktuelles Windows zu
portieren? Dass es dermaßen viel Ärger gibt sagt an sich schon mal etwas
über die Software aus ;-)) aber ich finde dass dies gar nicht geht.
Steff schrieb:> Aber bin ich eigentlich der Einzige der es extrem fragwürdig macht, was> Xilinx da praktiziert?
Nein, bist Du nicht.
Mit der momentanen Politik ist man gezwungen den Entwicklungsrechner
solange aufzuheben (und am Leben zu halten!), bis der Support für die
entwickelten Geräte ausgelaufen ist.
Richtig edel wäre es ja, wenn die Ihre verbuggte Software als open
source releasen würden. Dann hätte man zumindest eine Chance zur
Softwarepflege.
Das wird aber aus lizenzrechtlichen Gründen eine Illusion bleiben :-(
Duke
P.S.: Bei den anderen Herstellern scheint es aber auch nicht besser zu
sein, was die Softwarepflege angeht...
Ärgert mich auch, aber kann man wohl nichts dran machen. Ich finde auch
VIVADO ziemlich langsam. Gut die FPGAs heute sind recht fett, aber im
Vergleich zu Quartus fühlt sich das irre langsam an.
Vivado fühlt sich unglaublich langsam an, aber das gilt nicht für die
Algorithmen (zumindest empfinde ich die Synthese/Implementationszeiten
als akzeptabel - aber ich habe auch nur kleine Zynqs, da dauert das nur
ein paar Minuten, obwohl der FPGA fast voll ist).
Im Zweifelsfall sollte man die Entwicklung ausschließlich in einer VM
machen, denn die kann man beliebig lange warten, pflegen und auch bei
Bedarf umziehen.
S. R. schrieb:> Im Zweifelsfall sollte man die Entwicklung ausschließlich in einer VM> machen, denn die kann man beliebig lange warten, pflegen und auch bei> Bedarf umziehen.
Prinzipiell stimme ich Dir zu. Problematisch ist aber u.U. die Anbindung
der Programmierhardware.
Duke
Eine eigene Frage?
Dieser Thread ist über 9 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
