Forum: FPGA, VHDL & Co. XSVF Player an XC3S400


von stefan (Gast)


Lesenswert?

Hallo zusammen,
nachdem ich mir sämmtliche Threads zu Xsvf Programmieradaptern hier im 
Forum durchgelesen habe und dennoch nicht weiter komme eine kurze Frage 
in die Runde. Vielleicht habe ich ja bloss eine Kleinigkeit vergessen.

Zunächst erstmal zum Aufbau. Ich habe einen AT91SAM9 mit Linux auf 
welchem ich nach XAPP058 den XSVF Player laufen habe. Die I/O's 
registriere und spreche ich zunächst über /sys/class/gpio/gpioXX/... an 
und lese auch darüber. Das FPGA ist auf einem Altium LiveDesign 
Evalboard und die 4-JTAG Signal sowie die Massen beider Boards direkt 
miteinander verbunden. Auch hab ich die Timings (für die wait-Schleife 
in den ports.c sourcen) getrimmt. Funktioniert ebenfalls soweit nach 
Tests mit dem Oszi. Anschließend wurde ein XSVF File via Impact erzeugt 
welches die ID des FPGA's ausliest. Dieses läuft mit dem XSVF-Player 
durch und bringt mir die Meldung "SUCCESS - Completed XSVF execution." 
Wenn ich jetzt das FPGA programmiere (XSVF File ca. 210kB, dauert noch 
sehr lang(ca. 1000s bei einer Clk Frequenz von ca. 1.7kHz)) läuft auch 
dies bis zum Ende durch und zeigt mir die "SUCCESS ..." Meldung. Jedoch 
startet das FPGA nicht sein eigentliches Programm.

Gibt es vielleicht noch ein bestimmtes Signal-Schema welches 
anschließend nötig ist um das FPGA zu startet, JTAG abzukoppeln ...??? 
Ich bin hier ratlos.

Ich werde wohl nicht drum herum kommen mir die JTAG spec genauer 
anzuschauen. Für jeden Hinweis wäre ich sehr dankbar! Auch habe ich 
leider keine Möglichkeit eine andere Hardware/Device zu beschrieben.

Vielen Dank im Voraus für Eure Infos und Ratschläge.


Gruß Stefan

von stefan (Gast)


Lesenswert?

Kann es sein, dass nach dem Programmieren noch eine art RESET "Befehl" 
aktiviert werden muss?

von Bürovorsteher (Gast)


Lesenswert?

Impact - Programming Properties - letzte Zeile: "Load FPGA"

Beim normalen Impact-Programmieren ist hier ein Haken zu setzen, wenn 
der FPGA sofort nach dem Programmieren loslaufen soll. Ansonsten erst 
Strom aus und wieder an, um den FPGA aus dem Konfigurations-Prom zu 
laden.

Keine Ahnung, wo das beim XSVF ist.

von Bronco (Gast)


Lesenswert?

Was sagt denn der "DONE"-Pin des FPGAs?
Wenn ich es richtig weiß, müßte dieser nach erfolgreicher Konfig von 0 
auf 1 gehen.

von stefan (Gast)


Lesenswert?

Wow, vielen Dank für die ersten schnellen Infos.

@Bürovorsteher
Ich habe kein Prom auf dem Board, so dass ich nach einem Power-Reset das 
FPGA neu flashen muss. Dementsprechend kann ich die Option "Load FPGA" 
im Impact nicht auswählen, da sich kein PROM Device in meiner Chain 
befindet. Die einzige mögliche Option "Pulse PROG" hat eher was mit der 
Initialisierung zu tun und behebt das Problem demnach auch nicht.

@Bronco
Richtig, er müsste von '0' auf '1' springen. Macht er aber leider nicht, 
sondern bleibt auf '0'.

von berndl (Gast)


Lesenswert?

war da nicht noch was mit Clock noch laenger toggeln lassen? Ich 
konfiguriere hier einen FPGA von einem uC aus ueber die Flash-Leitungen, 
da brauche ich das (siehe xapp502)

von Georg A. (georga)


Lesenswert?

> war da nicht noch was mit Clock noch laenger toggeln lassen?

Das lag aber AFAIR an den Startup-Optionen, die man bei bitgen setzen 
kann.

von stefan (Gast)


Lesenswert?

Danke berndl, danke Georg A.
ich bin die App-Notes durchgegangen und habe sowohl danach mit TDI='1' 
den clk 100000 mal "nachtoggeln" lassen. Ebenfalls habe ich in den 
Startup-Options für BitGen den StartupClk auf JTAG geändert. Auch eine 
Deaktivierung von DLL Lock oder DCI Match auf "no wait" bringt leider 
keinen Unterschied.

von stefan (Gast)


Lesenswert?

Hallo zusammen,
erst einmal ein Dankschön an alle, die mir bisher versucht haben weiter 
zu helfen.

Hier die Info für diejenigen, welche ebenfalls verzweifelt suchen woran 
es lag. Grundsätzlich funktionieren die Standard-BitGen Einstellungen 
und es sind hier keine Modifikationen nötig.

Ich habe Variante "2" der waitTime(...) Funktion in ports.c verwendet, 
und schon funktioniert es. Diese scheint für langsamere TCK Zyklen 
(<1MHz) zu sein. Ich liege aktuell für f_TCK bei ca. 150kHz. Das sleep 
ist dabei nicht nötig, es ist lediglich wichtig, dass TCK==0 ist.

Vielen Dank nochmal für Eure Hilfe!

Gruß Stefan

Bitte 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
Noch kein Account? Hier anmelden.