Hallo! Ich wundere mich über das im Titel dieses Threads beschriebene Problem. Ich verwende ein crosslink-nx von Lattice, um Videoschnittstellen anzupassen. Und während der Serienproduktion des PCBAs funktionieren 10% der Einheiten nicht wie erwartet. Im Normalbetrieb sollte der FPGA ein RGB-Display ansteuern, das ein klares Balken-Testmuster des pic1 anzeigt. Die ausgegebenen PCBAs zeigen jedoch das folgende Verhalten des pic2 Das Problem scheint stark temperaturabhängig zu sein, denn nach einigen Minuten Betrieb funktioniert es einwandfrei und zeigt das im ersten Bild gezeigte klare Farbtestmuster an. Das Problem tritt jedoch immer bei niedrigen Temperaturen auf (typischerweise unter 0 Grad). Nachdem ich die korrekten Formen aller RGB-Schnittstellensignale überprüft und gemessen habe, habe ich beschlossen, den SPI-Speicher des FPGAs neu zu flashen, und das hat alle Probleme in allen problematischen PCBAs gelöst. Hat jemand eine Idee, was passieren könnte? Ich wäre für jeden Hinweis oder Tipp dankbar, um dieses Thema weiter zu erforschen. Vielen Dank im Voraus. Grüße.
Enrique P. schrieb: > Das Problem scheint stark temperaturabhängig zu sein Das könnte auf ein Timingproblem hindeuten, verursacht durch z.B. falsche oder fehlende Constraints, falscher Speedgrade eingestellt etc. > den SPI-Speicher des FPGAs neu zu flashen, und das hat alle Probleme in allen problematischen PCBAs gelöst. Und das neu geflashte Bitfile ist exakt identisch mit dem vorherigen? Falls es neuer Synthesedurchlauf ist, siehe oben. Dass der Bitstream im SPI-Flash durch Speicherverlust korrumpiert sein könnte, ist auszuschließen, da in einem solchen Fall beim Laden des Bitstreams die CRC-Prüfung fehlschlägt und damit die Konfiguration des FPGAs verhindert wird. In so einem Fall macht das FPGA genau gar nichts ;-)
Falls es ein Wärmeproblem sein sollte, hilft Fön, Trichter und Kältespray bei der Suche. Es gibt jedoch auch wunderliche Zeit- und Speicherprobleme auf dieser Welt.
> Hat jemand eine Idee, was passieren könnte? Ich wäre für jeden Hinweis > oder Tipp dankbar, um dieses Thema weiter zu erforschen. Studiere Digitaltechnik, diesbezüglich scheinen dir ja einige Grundlagen zu fehlen.. An den Bildern kann man erkennen, das die Farbgenerierung über einen counter o.ä. der die aktuelle Position in x-Richtung ermittelt, realisiert ist. In Fehlerfall scheint der Zähler invers zu laufen (von Dunkelblau nach Hellrot statt von Hellrot nach Dunkelblau wie pic1). Auch scheint dieser counter im Fehlerfall nicht korrekt ge-resetet zu werden, weshalb die Zeilenden untereinander "ausfransen". Mit den dürftigen Informationen kann man jetzt nicht tiefer analysieren warum das so ist, mglw. liegt das Problem eher an einem externen Baustein der Signal an den FPGA zuliefert (Taktgeber, Resetgenerator, rückgeführter H/V-Sync). Bei jedem Flashen sollte nicht nur die veränderliche Logik neu programmiert werdeb, sondern es wird auch ein interner Reset generiert und losgelassen, auch die PINS werden in einen bestimmten Zustand während der konfigzration gehalten und interne PLL's starten ihren Regelkreis neu. Möglicherweise passt da beim ersten konfigurzeren etwas nicht, die Startphase ist zu kurz o.ä.. http://padley.rice.edu/cms/OH_GE21/UG470_7Series_Config.pdf Bei manchen FPGA's kann man einstellen, wie ein "Konfiguration OK" Signal erzeugt wird, und ob man im Fehlerfall automatisch einen erneuten Versuch startet. Power-On-Ramping der Powersupplies ist auch so ein Überprüfungskanditat.
Enrique P. schrieb: > Das Problem tritt jedoch immer bei > niedrigen Temperaturen auf (typischerweise unter 0 Grad). > ...und das hat alle Probleme in allen problematischen > PCBAs gelöst. Auch nachdem diese Platinen wieder auf niedrige Temperaturen gebracht wurden? Nicht, das die vom Flashen noch 'warm' waren. Pat A. schrieb: > Das könnte auf ein Timingproblem hindeuten, verursacht durch z.B. > falsche oder fehlende Constraints, falscher Speedgrade eingestellt etc. In die Richtung würde ich auch suchen.
Hallo Leute! Danke für eure Antworten. Endlich ist das Problem gelöst. Es wurde eine falsche FPGA-Version in der Produktion verwendet. Vielen Dank für eure Unterstützung.
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.