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.
Angehängte Dateien:
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:
1 | setMode -bscan |
2 | setCable -port auto |
3 | Identify -inferir |
4 | identifyMPM
|
5 | attachflash -position 1 -spi "W25Q64BV" |
6 | assignfiletoattachedflash -position 1 -file "filename.mcs" |
7 | Program -p 1 -dataWidth 4 -spionly -e -v -loadfpga |
8 | closeCable
|
9 | quit
|
Duke
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.
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.