Forum: FPGA, VHDL & Co. Boundary Scan Probleme Spartan 3e


von Christian R. (supachris)


Lesenswert?

Wir haben hier ein kleines Problem mit dem Spartan 3e aund Boundary 
Scan. Und zwar: Xilinx sagt, dass das Original-BSDL File (natürlich) nur 
gültig ist, wenn der FPGA unkonfiguriert ist, und man nur in diesem 
Zustand Boundary Scan machen sollte. Soweit klar. Wir arbeiten mit 
Cascon von Göpel. Nun haben wir extra einen Jumper an die Init Leitung 
gemacht, um zu verhindern, dass der Spartan aus dem Flash bootet, um die 
Platinen zu testen. Das klappt auch, der FPGA wird nicht geladen. 
Allerdings ist dann auch kein Boundary Scan möglich, die SAMPLE 
Instruktion wird einfach ignoriert und die JTAG Kette kann nicht 
aufgebaut werden. Mit iMPact geht trotz gestecktem Jumper allerdings 
programmieren, Auslesen usw. Wir waren jetzt schon bei Göpel, die sind 
auch erst mal ratlos, das hatten sie auch noch nicht. Ist der FPGA 
geladen, ist Boundary Scan möglich, alllerdings dann halt nur 
eingeschränkt mit dem bsdlanno File. Hat das jemand schon mal gehabt? 
Oder haben wir und Göpel was in dem tausenden Seiten Doku zum Spartan 3e 
übersehen?

von gast (Gast)


Lesenswert?

ich kenne mich mit bs zu wenig aus, aber es gibt doch dort mode pins mit 
denen man die config bestimmt - muessen die für bs auch gesondert 
eingestellt werden?

von Christian R. (supachris)


Lesenswert?

Nee, die betreffen nur das Booten, und bestimmen auf welche Art der FPGA 
geladen werden soll. Mit denen ist alles OK. Vielleicht antwortet Xilinx 
ja (irgendwann) auf die Support-Anfrage von Göpel.

von Falk B. (falk)


Lesenswert?

Nutze den Jumper, um den FPGA zeitweise von Maser Serial auf Slave 
Serial einzustellen. Dann braucht man auch nicht das INIT "abwürgen" und 
BSCAN sollte problemlos laufen.

MFG
Falk

von Sascha P. (saschap)


Lesenswert?

Hi,

Gibt es hierfür schon eine Lösung ?

Wir probieren ähnliches mit der Göpel SW und einem Spartan 3 an einem 
DSP und weiteren EEPROMs in der Boundary Scan Kette, haben aber ein 
seltsames evtl. ähnliches Phänomen:

Im konfigurierten Zustand (valides Design im FPGA prom) läuft unser 
BoundaryScan Test, aber die Stromaufnahme ist bei 1A zu hoch. Selbst bei 
einem Abschalten der Peripherie (DSP im Reset) haben wir zu höhe Ströme.

Nutzen wir hingegen ein unkonfiguriertes Prom (gelöscht mit iMPACT, kein 
valides Konfigurationsfile) haben wir zwar eine zu erwartende 
Stromaufnahme und können auch mit den Ausgängen wackeln, lesen aber nur 
"1" aus Eingängen zurück.

Hat jmd eine Lösung parat ?

Gruß, Sascha

von Christian R. (supachris)


Lesenswert?

Hm, ich weiß jetzt auf die Schnelle gar nicht mehr, woran das wirklich 
lag. Auf jeden Fall ging es dann bei uns. Ich glaube, da war was mit den 
IDT Fifos, die auch in der Kette waren, und deren TRST. Soweit ich mich 
erinnere, hat der Spartan 3e beim Eintritt in den EXTEST Modus irgendwas 
an genau dem IO gewackelt, an dem parallel der TRST des IDT FIFOs hing, 
somit hat der sich selbst die JTAG Kette entzogen.

Zu dem Problem mit der Stromaufnahme weiß ich momentan auch nix. Könnte 
höchstens sein, dass Cascon nicht alle Bedingungen korrekt erkannt hat 
und irgendwelche Ausgänge zwischen BS-fähigen und nicht-BS-fähigen 
Bausteinen einen Konflikt gibt. Sowas kommt schon mal vor. Ein 
gelöschtes PROM ist aber auch ungünstig, weil dann der Spartan versucht, 
das File zu laden, aber dann hängen bleibt. Sichere Variante ist das 
Ziehen des PROG_B oder INIT_B gegen Low mit einem Jumper. Beim S3 gehts 
mit PROG_B auf jeden Fall, beim Virtex 4 hingegen bleibt auch die JTAG 
Kette mit PROG_B = Low stehen.

von Matthias G. (mgottke)


Lesenswert?

Ich verstehe nicht so recht wo das Problem liegen sollte?
Wir führen die BS-Tests immer vor der Programmierung aus. Schließlich 
will man mit BS ja die Leiterplatte und die Bestückung testen. An dieser 
Stelle braucht man noch keinen programmierten FPGA. Unser Prüffeld hat 
die Anweisung vor einem BS-Test gegebenenfalls den Config-PROM zu 
löschen.

von Sascha P. (saschap)


Lesenswert?

Hallo,

wir haben während der Entwicklung teilweise mehrere Programmierungen 
vorgenommen. Somit waren die Proms schon mit Daten gefüllt. Zudem war 
die Löschroutine der Proms noch nicht verifiziert, sodaß Unsicherheit 
herrschte, ob der FPGA nun aus dem PROM bootet oder nicht.

Die Löschroutine konnten wir jetzt mit iMPACT verifizieren - sie 
funktioniert. Diese führen wir auch vor jedem BS Test aus.

Das Problem mit den zu hohen Strömen lag in unserem FPGA Design. Bei 
einer Überarbeitung des Designs und korrekter I/O Zuweisung war dann 
auch die Stromaufnahme wieder in gewünschten Größen. Wir können jetzt 
auch mit der aktuellen Software von Göpel unsere BS Tests durchfahren.

Für das Eingangs geschilderte Problem hilft dann wohl ein SW Update.

Gruß, S.P.

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.