Xilinx impact idcode mismatch

bei Impact den JTAG-Clock runtersetzen

Danke! Werde ich nachher versuchen!
Gebe dann Bescheid.

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.

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...

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