Spartan 3 Configuration

Las das Verify mal weg.
Wenn nach dem Programmieren(ohne Verify) keine Fehlermeldung kommt ist 
alles im FPGA angekommen.

Gruß

Dirk

Ohne Verify wird einfach "Program failure" ohne zusätzliche 
Fehlermeldungen anzeigt.

@Johnsn

>Ohne Verify wird einfach "Program failure" ohne zusätzliche
>Fehlermeldungen anzeigt.

Klingt nach Übertragungsproblemen. Mach mal den ID Loop Test mit 10000 
und mehr Durchläufen. Die FPGAs sind bekannt für ihre Emfindlichkeit 
gegenüber unsauberen Signalen an TCK. Die Schaltung löst das Problem

http://www.geocities.com/jacquesmartini/misc/Parallel_Cable_III.png

MfG
Falk

Der IDLOOP Test wird mit 10000 und 100000 loops bestanden.

Beim Umstieg auf 9.1 hatte ich ein ähnliches Problem.
Erstelle ein neues Bitfile mit folgenden Einstellungen:
Configuration Options --> Configuration Rate 3

Gruß

Dirk

Ich hatte gerade ein Telefonat mit einem Service-Techniker. Er erklärte 
mir gleich mal vorweg, dass ISE ohne aktuellem Service-Pack 
grundsätzlich nicht funktionsfähig wäre. Kann das jemand bestätigen?

Als Programmierkabel verwende ich die Revision 3 und auch hier glaubte 
der Techniker, dass der Spartan 3 einfach zu "neu" für das 
Programmierkabel ist und deshalb bei größeren Bitfiles (zB eines FPGA) 
es zu Übertragungsfehlern kommen kann, aufgrund der schlechten 
Parallelports in heutigen PCs. Meine Frage an euch: Habt ihr schon mal 
ein Spartan 3 mit Programmierkabel 3 erfolgreich konfiguriert?

mfg Johnsn

@Johnsn

>Ich hatte gerade ein Telefonat mit einem Service-Techniker. Er erklärte
>mir gleich mal vorweg, dass ISE ohne aktuellem Service-Pack
>grundsätzlich nicht funktionsfähig wäre. Kann das jemand bestätigen?

Ohhh wehhh! Wo sind wir hingekommen.

>Als Programmierkabel verwende ich die Revision 3 und auch hier glaubte
>der Techniker, dass der Spartan 3 einfach zu "neu" für das
>Programmierkabel ist und deshalb bei größeren Bitfiles (zB eines FPGA)
>es zu Übertragungsfehlern kommen kann, aufgrund der schlechten
>Parallelports in heutigen PCs. Meine Frage an euch: Habt ihr schon mal

Da macht sichs mal wieder jemand ziemlich einfach.

>ein Spartan 3 mit Programmierkabel 3 erfolgreich konfiguriert?

Ja, ich. Sowohl mit dem Original als auch der verbesserten Version aus 
dem Link, damit wirds wasserdicht.

MfG
Falk

Ich auch.

Ich habe gerade das Service Pack 2 installiert und die Regel, dass nach 
einem Update weniger geht als vorher bestätigt sich. DeviceID, Signature 
und IDLOOP funktionieren noch, allerdings beim Program-Versuch bleibt 
die Progress-Anzeige bei 0% stehen. Wenn ich das Kabel abziehe, läuft 
der Progress an, obwohl kein Chip mehr am Programmierkabel hängt und 
"Program succeeded" taucht auf. Da ist doch irgendwas faul?

@Johnsn

>Ich habe gerade das Service Pack 2 installiert und die Regel, dass nach
>einem Update weniger geht als vorher bestätigt sich. DeviceID, Signature

Software!!! Die 8. Plage der Menschheit. Haben wir Pest, Cholera und TBC 
überwunden, rafft uns nun der ServicePack-Wahn dahin. Von wegen Homo 
Sapiens!

>"Program succeeded" taucht auf. Da ist doch irgendwas faul?

Das kannst du laut sagen.

MFG
Falk

@Falk: Ich habe gestern abend auch noch das Programmiergerät 
modifiziert, ähnlich wie dein Aufbau, hat aber auch nichts gebracht. Wir 
haben jetzt das USB-Programmiergerät bestellt, das kommt aber erst in 10 
Tagen.

Auf dem Board hängt auch noch ein Mikrocontroller dran. Mein nächster 
Plan wäre also, das FPGA per Slave Serial zu konfigurieren. Jedoch zieht 
mir dabei das FPGA während des Proprammiervorgangs den INIT_B Pin auf 
Low, was soviel bedeuted, wie CRC-Error, laut Flußdiagramm auf Seite 48 
im Spartan3-Datenblatt. Beim Slave Serial Modus, brauche ich nur einen 
low-pulse auf PROG_B geben. Und nachdem INIT_B darauf reagiert hat und 
wieder high geworden ist, kann ich via SPI die Binärdaten (natürlich 
ohne Headerinformation) reinspielen. Wenn alle Bits reingespielt wurden 
wird DONE auf high gezogen und die das FPGA-Design müsste laufen. Ist 
das so, oder muss ich auf irgendwas speziell achten?

mfg
Johnsn

@Johnsn

>@Falk: Ich habe gestern abend auch noch das Programmiergerät
>modifiziert, ähnlich wie dein Aufbau, hat aber auch nichts gebracht. Wir

Was heisst ähnlich? RC-Filter und Schmitt-trigger?

>haben jetzt das USB-Programmiergerät bestellt, das kommt aber erst in 10
>Tagen.

Wenn es die beschriebene Schaltung nicht tut, dann sehe ich auch für das 
USB-Kabel schwarz.

>Auf dem Board hängt auch noch ein Mikrocontroller dran. Mein nächster
>Plan wäre also, das FPGA per Slave Serial zu konfigurieren. Jedoch zieht
>mir dabei das FPGA während des Proprammiervorgangs den INIT_B Pin auf
>Low, was soviel bedeuted, wie CRC-Error, laut Flußdiagramm auf Seite 48

Ja, das ist richtig.

>im Spartan3-Datenblatt. Beim Slave Serial Modus, brauche ich nur einen
>low-pulse auf PROG_B geben. Und nachdem INIT_B darauf reagiert hat und
>wieder high geworden ist, kann ich via SPI die Binärdaten (natürlich
>ohne Headerinformation) reinspielen. Wenn alle Bits reingespielt wurden

Kannst du auch mit Header schicken, es gibt ein SYNC Wort.

>wird DONE auf high gezogen und die das FPGA-Design müsste laufen. Ist

Soweit die Theorie ;-)

>das so, oder muss ich auf irgendwas speziell achten?

MSB/LSB Reihenfolge der Daten sowie nach der Übertragung aller 
Konfigurationsdaten werden noch ein paar Takte (6..10) gebraucht, um das 
FPGA zu starten. Ausserdem muss in den Optionen für Bitgen CCLK als 
Starttakt ausgewählt werden.

MFG
Falk

Hi Falk!

Danke für deine Hinweise. Ich habe noch ein paar Fragen:

Was hat es mit dem SYNC-Wort auf sich bzw. ist das optional?
Wenn das FPGA mit den zusätzlichen CCLK Cycles noch nicht gestartet 
wurde, ist DONE bereits auf HIGH oder erst nach dem eigentlichen 
Startup?
Darf der Clock bei Inaktivität high sein?

lg Johnsn

@Johnsn

>Was hat es mit dem SYNC-Wort auf sich bzw. ist das optional?

Das steht ganz am Anfang der eigentlichen Konfigurationsdaten. Das FPGA 
sucht danach, erst dann begint der Ladevorgang. Sämtlicher Müll der 
davor in FPGA gestopft wird geht nach dev/null.

>Wenn das FPGA mit den zusätzlichen CCLK Cycles noch nicht gestartet
>wurde, ist DONE bereits auf HIGH oder erst nach dem eigentlichen
>Startup?

Das ist der Fallstrick, DONE geht nach der Konfiguration aber noch vor 
dem Startup auf HIGH. Ist sogar einstellbar in welcher Phase (Bitgen 
Optionen).

>Darf der Clock bei Inaktivität high sein?

Wenn du CCLK meinst, der kann nach der Konfiguration machen was er will, 
auch wild zappeln.

MfG
Falk

Ich hab jetzt alles beachtet, was du gesagt hast, leider geht die Konfig 
über SlaveSerial immer noch nicht.

Beim Versuch ein Testfile zu schicken (nur um zu sehen, ob das Protokoll 
ansich stimmt), ist mir bei CCLK aufgefallen, dass im Idle Zustand die 
Spannung bei 2.5V liegt, während der Kommunikation aber ein Pegel von 
ca. 3.06V vorliegt. Ich habe die gesamte Übertragung mal mitn Scope 
aufgezeichnet und angehängt.

Auch der PROG_B erreicht kein höheres Level als 3.06V, dass kommt 
allerdings von den Serienwiderständen von 100Ohm, die zur 
Strombegrenzung dienen. Können die verfehlten Spannungspegel (besonders 
die 2.5V auf CCLK während Idle) die Ursache für eine fehlerhafte 
Übertragung sein?

lg Johnsn

@Johnsn

>Beim Versuch ein Testfile zu schicken (nur um zu sehen, ob das Protokoll
>ansich stimmt), ist mir bei CCLK aufgefallen, dass im Idle Zustand die
>Spannung bei 2.5V liegt, während der Kommunikation aber ein Pegel von

Ähhh, CCLK und & Co hängen beim S3 glaub ich an VAUX, das sind 2.5V. 
Hast du das beachtet? Sind die Mode-Pins richtig gesetzt?

>Auch der PROG_B erreicht kein höheres Level als 3.06V, dass kommt

Das ist bei 2.5V IO Spannung schonmehr als genug.

>allerdings von den Serienwiderständen von 100Ohm, die zur
>Strombegrenzung dienen. Können die verfehlten Spannungspegel (besonders
>die 2.5V auf CCLK während Idle) die Ursache für eine fehlerhafte
>Übertragung sein?

Was heisst Idle? Dein uC treibt CCLK, dementsprechende Pegel liegen dann 
am FPGA.

MfG
Falk

Ja schon klar, das mit VAUX = 2.5V, allerdings hat mein MasterDevice 
(der uC) Spannungspegel von 3.3V an seinen Pins. Deshalb will ich die 
3.3V-kompatible SlaveSerial Konfiguration machen.

Die Mode-Pins sind alle auf 2.5V gesetzt, also {111}.

Mit Idle meine ich den Fall, wenn die SPI vom uC nicht arbeitet, 
womöglich werden die Pins dann hochohmig?!

@Johnsn

>Ja schon klar, das mit VAUX = 2.5V, allerdings hat mein MasterDevice
>(der uC) Spannungspegel von 3.3V an seinen Pins. Deshalb will ich die
>3.3V-kompatible SlaveSerial Konfiguration machen.

Mit 100 Ohm Serienwiderständen? Das passt. Dann ist auch klar warum am 
FPGA 3V anliegen, 2,5V + 0,5 (Klemmdiode nach VAUX)

>Mit Idle meine ich den Fall, wenn die SPI vom uC nicht arbeitet,
>womöglich werden die Pins dann hochohmig?!

Nicht wenn man es nicht explizit programmiert.

MfG
Falk

Also passt die Konfiguration, oder was meinst du soll ich jetzt ab 
besten machen?

@Johnsn

>Also passt die Konfiguration, oder was meinst du soll ich jetzt ab
>besten machen?

Aus der Distanz schwer zu sagen. Hast du mal LSB/MSB first pobiert? Was 
macht INIT_B? So ein FPGA ist eigentlich nicht allzuschwer zu 
konfigurieren. Aber McMurphy . . .

MfG
Falk

INIT_B verhält sich jetzt ruhig, also bleibt brav auf high.
LSB first, hat nichts geändert.

Ist zwar schon ein Weilchen her..

Vorgestern habe ich die Konfiguration eines SpartanII über JTAG 
geschafft.

Problem war in meinem Fall das SPI-Kabel, welches mit dem Testkit kam. 
Die alte veröffentlichte Schaltung "Xilinx Paralleles Kabel III" reicht 
nicht aus, um ein funktionsfähiges Kabel zu erstellen, sondern man muss 
bei dem eigentlichen Anschlusskabel beachten, dass die aktuellen FPGAs 
auf dem TDO-Pin sub-nsec Flanken produzieren. Die 10 cm Kabel vom FPGA 
bis zum Paralleladapter sollten also mit kontrollierter Impedanz gebaut 
werden, am einfachsten mit Flachbandkabel in 50 Ohm, wobei immer 
zwischen zwei Signalen und am Rand des Kabels ein Gnd liegt. Wenn man 
dann noch die 100 Ohm Widerstände auf dem Adapter in 33 oder 50 Ohm 
ändert und die 2,5V / 3,3V / 5V richtig macht, dann funktioniert es 
zuverlässig.

Das Problem ist also weniger die Schaltung des Paralleladapters, sondern 
die Ausführung der Leitungen. Übrigens gilt dasselbe für die anderen 
Signale am FPGA, sonst kann man die Abstrahlungen sogar mit dem Scope 
sehen...

Ok danke für den Tipp. Ich habe gerade versucht die Glitches mit 
verschiedenen Rs und Cs zu dämpfen. Nützte aber nix. Ich muss noch dazu 
sagen, dass ich mittlerweile das "offizielle USB-Programmierkabel von 
Xilinx" habe. Und dieses Mistding wirft noch immer diesselben Fehler 
aus!

Ach so, in dem Flachbandkabel müssen die Gnd-Leitungen an beiden Enden 
kurz verbunden sein.

Bei mir sind auch nochmal Fehler aufgetreten, und zwar weil ich bzw. ISE 
anscheinend Kurzschlüsse programmiert hatte. In meinem Testkit sind 
etliche Peripheriebausteine mit harten Ausgängen, z.B. Clock, Interrupt, 
Ausgänge von RS-232-Pegelwandler usw., die ich erstmal ignoriert hatte. 
Anscheinend kam es irgendwie zu Kollisionen, der FPGA wurde auch etwas 
warm. Also habe ich die betreffenden Leitungen als Eingänge belegt. Nun 
kommen im ISE zwar Warnungen wegen nicht verbundener Signale, aber der 
FPGA bleibt jetzt kalt und der Download funktioniert zuverlässig, auch 
mehrmals hintereinander.

@D. Teuchert

>Die alte veröffentlichte Schaltung "Xilinx Paralleles Kabel III" reicht
>nicht aus, um ein funktionsfähiges Kabel zu erstellen,

Das ist wohl leider wahr. Die Schaltunf ist argkomisch.


>bei dem eigentlichen Anschlusskabel beachten, dass die aktuellen FPGAs
>auf dem TDO-Pin sub-nsec Flanken produzieren. Die 10 cm Kabel vom FPGA

Das wage ich zu bezweifeln. Ausserdem schert sich der Parallelport einen 
Scheiss um sowas. Dieses Signal ist unkritisch.
Der Knackpukt ist TCK. Dieses Pin ist ein Takteingang, und dummerweise 
mit der selben sauschnellen Technologie gebaut wie die normalen IOs. 
D.h. es reagiert allergisch auf kleinste Unsauberkeiten des Taktes, 
welche bei langen Leitungen bzw. extrem schlechten Impedanzen der 
Leitungen entstehen können.

>Das Problem ist also weniger die Schaltung des Paralleladapters, sondern

Doch. Ein Schmitt-trigger wirkt Wunder.

http://www.geocities.com/jacquesmartini/digital/schematic/Parallel_Cable_III.png


@Johnsn

>Ok danke für den Tipp. Ich habe gerade versucht die Glitches mit
>verschiedenen Rs und Cs zu dämpfen. Nützte aber nix. Ich muss noch dazu
>sagen, dass ich mittlerweile das "offizielle USB-Programmierkabel von
>Xilinx" habe. Und dieses Mistding wirft noch immer diesselben Fehler

Naja, erstmal must du eindeutig nachweisen dass es Glitches sind. Wenn 
es selbst mit dem USB-Kabel nicht läuft, dann ist wahrscheinlich noch 
was anderes faul.

MfG
Falk

LÖSUNG:

Hallo!

Erstmal danke für dir zahlreichen Beiträge und Tipps wir sind nun der 
Sache auf den Grund gekommen.

Und zwar ist der PROG_B Pin nach dem PowerOn Reset auf Low gewesen. Dies 
hat die interne Statemachine in einen Zustand versetzt, der die 
anscheinend das Programmieren über JTAG ausgeschlossen hat. Fakt ist, 
dass jetzt, nachdem PROG_B explizit auf High gesetzt wurde alles 
wunderbar funktioniert, keine Glitches, keine sub-ns Peaks und ein 
USB-Progammierkabel haben wir auch umsonst bestellt grrrr.

Vielen Dank,
Johnsn

@ Falk
Nach dem Ärger zu urteilen, der in deinem Tonfall zum Ausdruck kommt, 
waren meine kostenlosen Hinweise die richtigen.

Also nicht verwirren lassen: Schmitt-Trigger auf der Druckerseite des 
JTAG -Adapters bringen nichts.

Das Problem sind die Glitches, die der TDO-Ausgang des Spartan auf seine 
eigene TCLK-Leitung einstrahlt. Dadurch werden aus einer aktiven 
TCLK-Flanke gelegentlich zwei oder noch mehr. Dass ist keine schwarze 
Kunst, sondern man kann so etwas mit einem passenden Digitalscope 
messen. Man wird die Glitches los, indem man das 10cm-Kabel mit 
kontrollierter Impedanz aufbaut, wie vorher von mir beschrieben.

@Johnsn

>Und zwar ist der PROG_B Pin nach dem PowerOn Reset auf Low gewesen. Dies

Wieso? Kein Pull-up bzw. hängt er in der Luft?

>hat die interne Statemachine in einen Zustand versetzt, der die
>anscheinend das Programmieren über JTAG ausgeschlossen hat. Fakt ist,

Der ganze FPGA (inclusive JTAG) ist im harten RESET.

@D. Teuchert

>@ Falk
>Nach dem Ärger zu urteilen, der in deinem Tonfall zum Ausdruck kommt,
>waren meine kostenlosen Hinweise die richtigen.

Vierfachfehler.

1.) Kein Ärger
2.) Tonfall?
3.) Deine "Hinweise" sind an den Haaren herbeigezogen.
4.) Das Problem war ein ganz anderes.

>Also nicht verwirren lassen: Schmitt-Trigger auf der Druckerseite des
>JTAG -Adapters bringen nichts.

Wenn du das sagst muss es ja stimmen.

>Das Problem sind die Glitches, die der TDO-Ausgang des Spartan auf seine
>eigene TCLK-Leitung einstrahlt. Dadurch werden aus einer aktiven

Jetzt wirds aber esotherisch. Aber auch duch permanante Wiederholung 
werden falsche Aussagen nicht richtig(er).

MFG
Falk, vollkommen entspannt ;-)

@Falk:

Das FPGA soll eigentlich von einem µC konfiguriert werden (SlaveSerial). 
Allerdings für ist für die Entwicklung des VHDL-Designs die 
JTAG-Konfiguration nicht so umständlich und "sicherer". Damit meine ich, 
dass man bei JTAG im Prinzip nichts falsch machen kann, weil die 
Software alles übernimmt. Allerdings wird PROG_B von einem CPLD 
getrieben, wo auch der Fehler liegt, weil nach dem POR das CPLD 
sämtliche Pins auf 0 zieht.


@D. Teuchert:
Danke für deinen Tipp, aber er hat definitiv nicht zu Problemlösung 
beigetragen!

@Johnsn

>Software alles übernimmt. Allerdings wird PROG_B von einem CPLD
>getrieben, wo auch der Fehler liegt, weil nach dem POR das CPLD
>sämtliche Pins auf 0 zieht.

???
Was ist das denn für ein CPLD?
Oder ist der so programmiert (Ausgang auf LOW)?
Normalerweise sind die IOs von unprogrammierten CPLDs auf Tristate (oder 
Pull-up).

MFG
Falk

@Falk:
Der CPLD ist so programmiert.

Du scheinst dich dich ja ziemlich gut mit der Materie auszukennen. 
Kannst du bitte noch mal einen Blick auf mein Oszilloskopdruck werfen, 
den hab ich am 14.03.2007 12:18 gepostet (weiter oben halt). Denn jetzt 
wo sich der S3 per JTAG programmieren lässt, kann ich Probleme wie 
Spannungsversorgung etc. ausschließen und die SlaveSerial-Konfiguration 
müsste auch funktionieren.

Tut sie aber leider noch nicht. Der Druck zeigt die gesamte Routine von 
Anfang bis Ende (gut an den Startup-Clock Zyklen zu erkennen, während 
die Daten auf LOW sind).

Fällt dir daran noch irgendein Fehler auf (die Pegel wurden direkt am 
FPGA-Pin gemessen)?

mfg
Johnsn

@Johnsn

>Du scheinst dich dich ja ziemlich gut mit der Materie auszukennen.

Ein wenig ;-)

>Spannungsversorgung etc. ausschließen und die SlaveSerial-Konfiguration
>müsste auch funktionieren.

Ja.

>Tut sie aber leider noch nicht. Der Druck zeigt die gesamte Routine von
>Anfang bis Ende (gut an den Startup-Clock Zyklen zu erkennen, während

??? Ende? Kaum. Dein 3S50 hat 439264 Bit Konfigurationsdaten, bei deinem 
SPI Takt von ca. 1MHz dauert das 439264 us zum Laden. Dein Screenshot 
zeigt aber gerademal ~300us Aktivität für CCLK/DIN. Falscher Byte-zähler 
in uC Programm?

>Fällt dir daran noch irgendein Fehler auf (die Pegel wurden direkt am
>FPGA-Pin gemessen)?

Der FPGA taktet die Daten mit der steigenden Flanke, bei dir wechseln 
sie mit der fallenden Flanke. Das ist also erstmal OK!
Bleibt noch MSB/LSB first als Fehlerquelle. Sowie die richtige Anzahl 
Konfigurationsdaten.

MFG
Falk

Also ich muss schon sagen, heute ist ein erfolgreicher Tag. Jetzt hab 
ich auch das Programmieren über SlaveSerial zustande gebracht. Der 
Fehler lag in der Polarität des SPI Clocks. Jedes Mal, wenn sich das SPI 
Interface vom µc von Bus zurückgezogen (high Z) hat, war zu diesem 
Zeitpunkt der Clock auf LOW und in Verbindung mit dem internen Pull-Up 
vom FPGA interpretierte selbiger dies als steigene Taktflanke.

Achja und sorry wegen der Scopeaufnahme. Du hattest Recht, das war nur 
ne Textdatei um zu sehen, ob das mit INIT und so funktioniert. Aber dir 
entgeht ja eh so schnell nix ;-)

@Johnsn

>Fehler lag in der Polarität des SPI Clocks. Jedes Mal, wenn sich das SPI
>Interface vom µc von Bus zurückgezogen (high Z) hat, war zu diesem
>Zeitpunkt der Clock auf LOW und in Verbindung mit dem internen Pull-Up
>vom FPGA interpretierte selbiger dies als steigene Taktflanke.

Sicher? Wenn der FPGA konfiguriert ist kann CCLK machen was es will. Nur 
PROG_B muss tunlichst auf HIGH bleiben (logo!).

>Achja und sorry wegen der Scopeaufnahme. Du hattest Recht, das war nur

Das macht ne Runde Freibier!

MFG
Falk

Ja sicher, weil das ist ja während der Konfiguration aufgetreten. Um 
Speicherplatz vom µc zu sparen schicke ich die Daten nömlich nur 
kB-weise rüber und zwischendurch wird das SPI interface deaktiviert.

@Johnsn

>Ja sicher, weil das ist ja während der Konfiguration aufgetreten. Um
>Speicherplatz vom µc zu sparen schicke ich die Daten nömlich nur
>kB-weise rüber und zwischendurch wird das SPI interface deaktiviert.

Spare jederzeit, dann hast du immer Not. ;-)
Software!!! ARRRGG!

MFG
Falk