Hallo zusammen! Ich sitze vor einem Board mit Spartan 3 XC3S50. Das Problem dabei ist, dass ich das Konfigurationsfile nicht erfolgreich in das FPGA spielen kann. Vorerst versuche ich mal per JTAG (Boundary-Scan) und Impact (von ISE 9.1 Webpack). Das FPGA ist alleine in der Kette und wird von der Software problemlos erkannt. Auch das Auslesen von Device ID und Signature ID funktioniert. Jedoch wenn ich ein Design (*.bit-file) reinspielen will, schlägt dies beim "verify" fehl, mit den beiden Error Messages: ERROR:Bitstream:98 - There are 1367 differences. ERROR:iMPACT:395 - The number of difference is 1367 Die Anzahl der "differences" bleibt bei jeden Versuch gleich. Die Spannungen 2.5V, 1.2V und 3.3V sind überprüft und die Schwellwerte werden in der gleichen Reihenfolge erreicht. Hier die exakte Bezeichnung des Chips: Device Type: XC3S50 Package: PQ(G) Pb-free: yes Number of Pins: 208 Mask Revision Code: E Fabrication Code: G Process Technology: Q Date Code: 0625 Lot Code: D2265096A Speed Grade: 5 Temperature Range: C Als JTAG-Kabel verwende ich ein selbstgebautes, allerdings funktioniert dies für CPLDs "XC9536" einwandfrei. Hat jemand eine Ahnung, wodurch die (konstante) Anzahl an Differences erzeugt werden könnte? Welche Fehlermöglichkeiten gäbe es sonst noch! Für Antworten wäre ich sehr dankbar! mfg Johnsn
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
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 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
Angehängte Dateien:
-
spi-scope.png
67 KB
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
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.