Hallo, ich benutze das Modul serdes_1_to_n_data_s8_diff der XAPP1064 auf einem Spartan6 unter EDK14.2. Ein 13-Bit-Bus mit 250MHz DDR wird in einen 91-Bit-Bus umgewandelt. Soweit funktioniert das ganze sehr gut. Bei mir auf dem Schreibtisch funktioniert es sogar BESTENS. Selbst wenn ich mit einem Störgenerator (mit kapazitiver Koppelstrecke von SCHLÖDER) Störungen von bis zu 2KV auf den Zuleitungen erzeuge, funktioniert alles gut --> irgendwann verabschiedet sich das Labornetzteil dann - aber das ist ein anderes Problem... :-) Jetzt mein PROBLEM: Beim Kunden (selbstverständlich über 1000km entfernt grrrrrr) scheint sich das SERDES-Modul nach kurzer Zeit aufzuhängen. Dann werden nur noch 0-Werte ausgegeben. Ich kann mir das überhaupt nicht erklären. Wenn man den RESET des serdes_1_to_n_data_s8_diff kurz auf '0' zieht, dann geht es wieder. Was noch sehr seltsam ist: Es gibt einige Geräte, bei denen tritt es innerhalb weniger Sekunden auf - bei anderen dauert es Tage, oder tritt nie auf. Ich würde ja auf den 250MHz-Oszillator tippen --> kann es sein, wenn sich dieser durch irgendwelche EMV stören lassen würde, dass solch ein Verhalten auftritt? Oder was könnte noch die Ursache sein, dass die SERDES auf einmal nur noch NULLEN ausgeben. Ich hätte halt erwartet, dass ein "aufgehängtes" SERDES gar nichts mehr ausgibt...??? Ich wäre für jede Hilfe oder Idee dankbar! Viele Grüße, Poolspieler
Es ist ein XC6SLX150-3FGG484I auf einem Trenz Gigabee Modul TE0600-01IVF. Angesteuert wird ein AD9613 auf einem EVA-Board: http://www.analog.com/en/evaluation/eval-ad9613/eb.html
Mir fällt gerade auf, dass im Datenblatt Speed Grade 2 angegeben wurde, auf der Verpackung (und vor allem auch auf der Platine) ist aber ein Speed Grade 3 verbaut --> könnte dies eventuell die Ursache sein? Eigentlich ja nicht, weil 3 ja besser ist als 2 --> ODER?
Die Frage ist, was auf euren Modulen verbaut ist und ob die SERDES an sich die Probleme machen und nicht gfs die PLLs. Woher kommen die Takte? Ich habe bereits SERDES mit dem Spartan6 gebaut, allerdings aus einem vormals funktionierenden Design eines V6, das spontan auf dem S6 nicht funktionierte. Ein Quell der Probleme ist die mangelnde Fähigkeit der Xilinx toolchain, cores von der einen zur anderen Core-Version zu übernehmen. In Einzelfällen klappt es nicht einmal ein Design innerhalb eines Chips auf eine neue Xilinx-Version upzudaten. Tipp: Immer alle Cores neu anlegen. Wie sieht es denn mit Spannungsversorgungen aus? Kann da was kommen? Laufen die Transceiver durch oder werden sie neu gestartet oder gesynched? Werden sie initial oder permanent eintrainiert? Sind die dynamic PLL-Eingänge und die IO-Delay configs belegt und/oder werden dort ändernde oder statische Werte eingeschrieben? Ich habe kein vollständiges Bild der Wirkung solch radikaler EMV-Aktivitäten, kann mir vorstellen, dass sich die Inputs irgendwas ziehen und sich verstellen. Bei RAMs hat es jedenfalls geholfen, sie redundant zu überschreiben - man "weiss" also, was drinstehen muss und schreibt es öfters wieder rein. Kurzfristige Fehler sind dann unerheblich. Wenn man es nicht in den Griff bekommt, alle Leitungen redundant ausführen und alternativ neu resetten und einstellen.
Hallo Jürgen, erstmal danke für Deine ausführliche Antwort! > Die Frage ist, was auf euren Modulen verbaut ist und ob die SERDES an > sich die Probleme machen und nicht gfs die PLLs. Woher kommen die Takte? Die Takte kommen von einem 250MHz Quarzoszillator --> dieser betreibt den AD-Wandler. Vom AD-Wandler kommen Takt und 13-Bit Datenbus zu den ISERDES des Spartan6. Wie gesagt: Der Oszillator auf einer kleinen Leiterplatte (ca. 2cm x 3cm)platziert. Diese Leiterplatte ist auf dem EVA-Board aufgeklebt und mit Fädeldrähten angeschlossen. Ich weiß, dass dies nicht schön ist, für die Prototypen war es aber (aus Zeitgründen) nötig... Nun ist halt die dicke Frage: Wenn der 250MHz-Clock wirklich ab und zu eine Störung hätte --> also irgend ein Spike auf dem Clock wäre: KÖNNTE dies dann dazu führen, dass die ISERDES zwar noch Daten ausgeben - aber eben nur noch NULLEN? > Ich habe bereits SERDES mit dem Spartan6 gebaut, allerdings aus einem > vormals funktionierenden Design eines V6, das spontan auf dem S6 *nicht* > funktionierte. Ein Quell der Probleme ist die mangelnde Fähigkeit der > Xilinx toolchain, cores von der einen zur anderen Core-Version zu > übernehmen. In Einzelfällen klappt es nicht einmal ein Design innerhalb > eines Chips auf eine neue Xilinx-Version upzudaten. Tipp: Immer alle > Cores neu anlegen. Das musste ich bei diversen Xilinx-Updates auch schon feststellen: Ein Update von z.B. EDK13 auf EDK14 kannst Du praktisch vergessen. Da ist der komplette Neuaufbau um einiges schneller und vor allem nervenschonender :-) Ich kann mir vorstellen, dass das Portieren zwischen verschiedenen Architekturen ähnlich problematisch ist... > Wie sieht es denn mit Spannungsversorgungen aus? Kann da was kommen? Naja, die sind halt vom EVA-Board. Tests beim Kunden haben aber gezeigt, dass die Störung wohl über die analogen Leitungen zum EVA-Board gelangen. Wenn die analogen Leitungen (SMA-Leitungen) nicht angeschlossen sind, dann tritt der Fehler NICHT auf. Schließt der Kunde aber eine 30cm kurze Leitung an, ohne das zweite Ende mit irgendwas in Verbindung zu bringen, dann tritt der Fehler auf. Die Coax-Leitung ist also eine Art Antenne, über die irgendwelche Störungen in mein Gerät kommen. Seltsamer Weise konnte ich es aber mit meiner kapazitiven Koppelstrecke NICHT reproduzieren. Ich habe mein Gerät damit gequält, bis das Labornetzteil abgeschmiert ist --> einen Fehler konnte ich nicht reproduzieren... :-( > Laufen die Transceiver durch oder werden sie neu gestartet oder > gesynched? Die laufen endlos. > Werden sie initial oder permanent eintrainiert? Einmal beim Systemstart wird eine komplette Rampe durch das Signal gefahren, um die Datenaugen einzulernen. Da hatte ich am Anfang auch Probleme mit korrupten Daten. Diese sind jetzt aber behoben. Ich habe keine einzelnen Ausreisser bzw. Datenfehler. Wenn der Fehler auftritt, dann kommt einfach nur noch NULL... > Sind die dynamic PLL-Eingänge und die IO-Delay configs belegt und/oder > werden dort ändernde oder statische Werte eingeschrieben? Ich nutze einen PLL von 2 weil die 250MHz ja mit DDR kommen - also bei der steigenden UND der fallenden Flanke kommen Daten. > Ich habe kein vollständiges Bild der Wirkung solch radikaler > EMV-Aktivitäten, kann mir vorstellen, dass sich die Inputs irgendwas > ziehen und sich verstellen. Bei RAMs hat es jedenfalls geholfen, sie > redundant zu überschreiben - man "weiss" also, was drinstehen muss und > schreibt es öfters wieder rein. Kurzfristige Fehler sind dann > unerheblich. > > Wenn man es nicht in den Griff bekommt, alle Leitungen redundant > ausführen und alternativ neu resetten und einstellen. Das wäre nun mein Workaround: Ich habe relativ kurze Messzeiten und relativ lange Wartezeiten. Die Wartezeiten könnte ich dazu nutzen, die SERDES zu Resetten - schön ist das nicht, würde aber wahrscheinlich helfen. Nur dann habe ich lediglich die Auswirkung bekämpft, ohne die Ursache zu kennen. Viele Grüße, Andreas
Andreas N. schrieb: > Ich nutze einen PLL von 2 weil die 250MHz ja mit DDR kommen - also bei > der steigenden UND der fallenden Flanke kommen Daten. Di Spartan 6 ISERDES können das doch auch ohne PLL. Welcher AD Wandler ist das? Liefert der den schnellen Takt synchron zu den Daten mit? Ich hab an mein SP605 den LTC2175 angeschlossen, mit eigener 4-Lagen Platte, das funktioniert sehr gut. Anfangs hatte ich ab und zu je nach Routing Durchlauf mal seltene korrupte Daten, aber wenn man die Constraints bissl anzieht, klappts. Core Generator braucht man da nicht mal, der erzeugt ja eh nur VHDL Code bei den SERDES. Ich hab dort ohne das IODELAY gearbeitet, das hat nur Stress gemacht, der Phasendetector ging überhaupt nicht, und fixes Delay ist auch Murks am Spartan 6. Der LTC liefert die Daten aber so dass man sie direkt mit dem Takt abtasten kann, also 90° verschoben, damit gehts prima.
Andreas N. schrieb: > Ein 13-Bit-Bus mit 250MHz DDR wird in einen 91-Bit-Bus umgewandelt. Das ist ein 1:7 Gearing, warum das denn? Ich habe mir Datenblatt des AD9613 mal angeschaut. Der kann wie Christian es für den LTC2175 tut ohne PLL verwendet werden. Als DDR-Inputclock in den FPGA dient DCO vom ADC. Das ist Laut Datenblatt gegenüber den Daten 0.4 - 1.0 (Typ 0.7) ns verschoben. Nicht gerade Centeraligned sollte aber gut genug sein.
Lass mich raten: Du hast den DCO nicht an einem GCLK in der gleichen halben Bank liegen wie alle Daten und Frame und daher der Umweg über PLL?
Christian R. schrieb: > Lass mich raten: Du hast den DCO nicht an einem GCLK in der gleichen > halben Bank liegen wie alle Daten und Frame und daher der Umweg über > PLL? Hallo Christian, Das ist richtig. Wobei es bei dem eingesetzten Modul gar nicht anders möglich war... > Ich habe mir Datenblatt des AD9613 mal angeschaut. Der kann wie > Christian es für den LTC2175 tut ohne PLL verwendet werden. Dafür müßte ich aber den Input-Clock von 250MHz auf 500MHz erhöhen. Das wäre eine Hardwareänderung, die ich schon vermeiden möchte. > Di Spartan 6 ISERDES können das doch auch ohne PLL. Welcher AD Wandler > ist das? Liefert der den schnellen Takt synchron zu den Daten mit? Ich > hab an mein SP605 den LTC2175 angeschlossen, mit eigener 4-Lagen Platte, > das funktioniert sehr gut. Anfangs hatte ich ab und zu je nach Routing > Durchlauf mal seltene korrupte Daten, aber wenn man die Constraints > bissl anzieht, klappts. Core Generator braucht man da nicht mal, der > erzeugt ja eh nur VHDL Code bei den SERDES. Ich hab dort ohne das > IODELAY gearbeitet, das hat nur Stress gemacht, der Phasendetector ging > überhaupt nicht, und fixes Delay ist auch Murks am Spartan 6. Der LTC > liefert die Daten aber so dass man sie direkt mit dem Takt abtasten > kann, also 90° verschoben, damit gehts prima. Wenn ich "nur" korrupte Daten hätte, dann würde ich das ja verstehen, und man müßte halt am Phasendetector (den ich erfolgreich verwende) schrauben - oder wo auch immer... ABER: Ich bekommen ja ENTWEDER korrekte Daten ODER lauter NULLEN! Wenn das Problem am PLL hinge, dann würde ich ja gar keine Daten mehr bekommen. Die Clocks kommen aber noch. Oder seht ihr das anders? aktuelle Fragen zum jetzigen Stand: 1. Könnte das Problem an dem falschen Speed Grade liegen (ich hatte Speed Grade 2 im EDK eingestellt - verbaut ist aber ein Speed Grade 3)? --> wird morgen getestet... 2. Was könnte bei den SERDES dazu führen, dass ausschließlich NULLEN kommen? (ist vielleicht wirklich der Phase detector daran schuld?) 3. Welche Möglichkeiten gäbe es, hier Debugging zu betreiben? - meine jetzigen Ansätze zum Debugging: a) Wenn der Fehler auftritt, dann kann ich über einen speziellen Befehl das SERDES-Modul dazu bewegen, definierte konstanten auszugeben (z.B. lauter FFs oder AAs) --> so kann ich alles was dahinter ist (DualportRAM, etc.) ausschließen b) Wenn bei a) rauskommt, dass es an den SERDES direkt liegt, dann bin ich erstmal mit meinem Latein am Ende --> WIE/WO kann ich weitere Debugings einfügen...??? Viele Grüße, Andreas
Andreas N. schrieb: > >> Ich habe mir Datenblatt des AD9613 mal angeschaut. Der kann wie >> Christian es für den LTC2175 tut ohne PLL verwendet werden. > Dafür müßte ich aber den Input-Clock von 250MHz auf 500MHz erhöhen. > Das wäre eine Hardwareänderung, die ich schon vermeiden möchte. > Nein. Auf der positiven Flanke von DCO kommen die Daten von Cannel A, auf der negativen Flanke die Daten von Channel B. Eine ganz normale DDR Anwendung, die jeder moderne FPGA out of the Box ohne zusätzliche Logik kann. Vorrausgetzt man verwendet die vorgesehenen Clockpins. Nochmal die Frage, warum 1:7 Gearing? Ich wette du bekommst nullen weil die dazugehörige Statemachine in einen nicht erlaubten Zustand gerät. Bei 1:2, 1:4, 1:8 ist alles was du brauchts eine passende Phasenverschiebung deiner falsch angeschlossenen Clock, die obendrein auch fest einstellbar sein kann.
Lattice User schrieb: > Andreas N. schrieb: >> >>> Ich habe mir Datenblatt des AD9613 mal angeschaut. Der kann wie >>> Christian es für den LTC2175 tut ohne PLL verwendet werden. >> Dafür müßte ich aber den Input-Clock von 250MHz auf 500MHz erhöhen. >> Das wäre eine Hardwareänderung, die ich schon vermeiden möchte. >> > > Nein. Auf der positiven Flanke von DCO kommen die Daten von Cannel A, > auf der negativen Flanke die Daten von Channel B. Eine ganz normale DDR > Anwendung, die jeder moderne FPGA out of the Box ohne zusätzliche Logik > kann. > Vorrausgetzt man verwendet die vorgesehenen Clockpins. Du meinst also, dass es ein Vorteil sein könnte, darauf umzustellen? Aber wenn ich Christian richtig verstanden habe, dann müssten alle Pins (Clock und Daten) auf der selben Bankhälfte sein --> und das ist bei mir halt leider nicht der Fall und vor allem mit dem verwendeten Modul auch nicht möglich... :-( > Nochmal die Frage, warum 1:7 Gearing? > Ich wette du bekommst nullen weil die dazugehörige Statemachine in einen > nicht erlaubten Zustand gerät. Naja, wenn man jetzt mal annehmen würde, dass aufgrund von EMV zwischen steigender und fallender Flanke des Clocks anstatt 2ns nur 1ns mal vorhanden ist, dann würde es sicherlich zu Problemen kommen können. Bleibt die Frage: wie will man das verhindern? Durch den Reset der Statemachine würde sie zumindest immer wieder in einen definierten Zustand gebracht. Im zweiten Schritt werde ich (was sowieso geplant ist) den "gefädelten" Oszillator auf ein ordentliches Layout bringen. Dann sollte das Problem ja eigentlich nicht mehr auftreten... > Bei 1:2, 1:4, 1:8 ist alles was du brauchts eine passende > Phasenverschiebung deiner falsch angeschlossenen Clock, die obendrein > auch fest einstellbar sein kann. Hier muss ich gestehen, habe ich eine falsche Information weiter gegeben. SORRY! Mit 1:7 hatte ich mal angefangen. Später habe ich es auf 1:8 umgestellt. Das Problem tritt also mit 1:8 auf - und nicht mit 1:7. Viele Grüße, Andreas
Andreas N. schrieb: > Aber wenn ich Christian richtig verstanden habe, dann müssten alle Pins > (Clock und Daten) auf der selben Bankhälfte sein --> und das ist bei mir > halt leider nicht der Fall und vor allem mit dem verwendeten Modul auch > nicht möglich... Genau so ist es. Wenn du den CLK direkt über den BUFIO2 verwenden willst, muss der an einem GCLK liegen, und alle Daten und Frame in der gleichen halbe Bank, weil die BUFIO2 auf die Bankhälfte beschränkt sind. Bei meinem SP605 ist das auch beknackt gelöst, das LTM9011 Board passt überhaut nicht dran, deswegen musste wir auch eine eigene Platine machen und erst mal nur den LTC2175 nehmen. Das läuft aber prima. Bei deinem Aufbau wirds wohl wirklich nur über die PLL gehen, wenn die Pins so verstreut liegen. Am SpeedGrade liegts sicher nicht, erst recht wenn der Chip die 3 hat (schneller) und in den Tools die 2 eingestellt war. Was bei mir noc für Datensalat gesorgt hat, war die Terminierung, ich musste den ADC auch intern terminiren, also beide Seiten, erst dann liefs sauber.
Sind die ARs zu den ISERDES (bzw. IODELAY, PHASE DETECTOR) bekannt: http://www.xilinx.com/support/answers/34856.htm ( Design Advisory Master Answer Record for Spartan-6 FPGA ) http://www.xilinx.com/support/answers/38408.htm http://www.xilinx.com/support/answers/41083.htm (da gibt es auch noch Unterschiede zwischen den Masken Revisionen!) Für die alten gilt zumindest: "IDELAY_TYPE=DIFF_PHASE_DETECTOR - The data rate must not exceed 400 Mb/s" zugegebenermaßen wird dort allerdings nur von "single bit errors" geredet. Ist der Aufbau der IODELAYS bekannt: Figure 2-20: Using Two Delay Lines Per Delay Block in Spartan-6 FPGA SelectIO Resources UG381 (v1.5) February 7, 2013 Könnte mir durchaus vorstellen, dass da etwas empfindlich auf Störungen im Eingangssignal reagiert. Stichwort "Ringoszillator", "Counter", unabhängige Behandlung von steigender und fallender Flanke. Bei solchen Problemen gehe ich üblicherweise nach der divide and conquer Methode vor, also Problem lokalisieren: - Wenn der Fehler auftritt, tritt er dann bei allen Inputs, sogar bei allen gleichzeitig oder nur bei einigen auf? Wenn immer alle gleichzeitig betroffen wären, sollte man annehmen, dass eine "gemeinsame" Komponente (wie Oszillator, PLL) betroffen ist, da Störungen sich eigentlich immer irgendwie stochastisch verhalten und es unwahrscheinlich, wäre, dass wenn die IODELAYS betroffen wären, dies bei allen immer identisch auftreten würde. - Auch wenn ich nicht dran glaube würde ich eine Abhängigkeit von der speed-grade Einstellung durch Erzeugen eines Bitstreams für den richtigen speed-grade ausschließen. - Eine Beteiligung der IODelays oder PDs könnte man relative einfach ausschließen, indem man sie einfach weglässt. Wenn die PLL auf 1GHz läuft müsste man die Phase des 250 MHz Ausgangstaktes auf 1ns einstellen können. Auch wenn dann noch ab und zu ein bit kippt, wäre das gut vom vollständigen Funktionsausfall (nur noch Nullen zu unterscheiden). Grundsätzlich muss ich sagen, dass ich mit den ISERDES + IODELAY + PD ganz gut zurecht komme. Unter Laborbedingungen läuft das auch mit 1Gbit/s ( 1:8 ) für Stunden ohne einen einzigen Bitfehler (bei mir ohne PLL mit 500 MHz source synchronous clock über die IOBUFs ).
Wie ist jetzt eigentlich was angeschlossen? Korrekt ist meiner Ansicht: Oscillator -> ADC CLK In ADC DCO -> FPGA Clock In Ich bin gerade an etwas ähnlichem, allerdings mit Lattice. Wie Christian fand ich es leichet und zuverlässiger das Interface mit den Grundprimitiven selber aufzubauen, statt den von IPExpress (aka CoreGen bei Xilinx) generierten zu verwenden. Braucht halt ausgiebigen Datenblatt Studium. bei 1:8 wird vermutlich ein Framesync Module vom CoreGen eingebaut, das du bei der vorliegenden Anwendung gar nichts brauchst. Und dieses Module ist vermutlich der Teil der durch die Störung ausser Tritt gerät und ein Reset braucht.
Christian R. schrieb: > Andreas N. schrieb: >> Aber wenn ich Christian richtig verstanden habe, dann müssten alle Pins >> (Clock und Daten) auf der selben Bankhälfte sein --> und das ist bei mir >> halt leider nicht der Fall und vor allem mit dem verwendeten Modul auch >> nicht möglich... > > Genau so ist es. Wenn du den CLK direkt über den BUFIO2 verwenden > willst, muss der an einem GCLK liegen, und alle Daten und Frame in der > gleichen halbe Bank, weil die BUFIO2 auf die Bankhälfte beschränkt sind. Ich bin Lattice User, d.h. ich kenne mich mit dem Spartan über das Datenblatt hinaus nicht aus, folgendes ist daher eventuell nicht gültig: Bei 250 MHz werden die schnellen EdgeClocks bei Lattice noch nicht gebraucht, d.h. es möglich eine globale Clock für alle Inputs zu verwenden. Max gearing ist aber dann 1:2, aber 125 MHz sollte im FPGA noch beherrschbar sein. man kann ausserdem intern in Logik mochmal mit 1:2 auf 62.5 MHz runtergehen.
Lattice User schrieb: > verwenden. Max gearing ist aber dann 1:2, aber 125 MHz sollte im FPGA > noch beherrschbar sein. man kann ausserdem intern in Logik mochmal mit > 1:2 auf 62.5 MHz runtergehen. Da habe ich mich vertan, interne Clock ist mit 1:2 250 MHz ist aber beherschbar, vorallem wenn man nichmal 1:2 nachschaltet.
Hallo zusammen, erstmal danke für Eure Antworten! > Wie ist jetzt eigentlich was angeschlossen? > Korrekt ist meiner Ansicht: > Oscillator -> ADC CLK In > ADC DCO -> FPGA Clock In Genau so ist es angeschlossen. Und die Fädelleitung ist zwischen Oscillator und ADC CLK In. Ich weiß, dass das nicht schön ist, aber es ging halt vorerst nicht anders... Ich habe jetzt mal versucht, eine "Störung" des Clocks zu simulieren (mit Modelsim). Dabei habe ich gesehen, dass tatsächlich Nullen für eine gewisse Zeit nach der Störung ausgegeben werden. Der PLL erkennt wohl, dass es nicht mehr im Takt ist und gibt rx_bufpll_lckd=0 aus. rx_bufpll_lckd geht auf den Reset des datain:serdes_1_to_n_data_s8_diff:
1 | clkin : serdes_1_to_n_clk_pll_s8_diff |
2 | generic map( |
3 | CLKIN_PERIOD => 4.0, |
4 | PLLD => 1, |
5 | PLLX => 2, |
6 | S => S, |
7 | BS => FALSE -- Parameter to enable bitslip TRUE or FALSE (has to be true for video applications) |
8 | )
|
9 | port map ( |
10 | clkin_p => clkin_p, |
11 | clkin_n => clkin_n, |
12 | rxioclk => rx_bufpll_clk_xn, |
13 | pattern1 => "00100001", -- default values for 7:1 video applications |
14 | pattern2 => "00100011", |
15 | rx_serdesstrobe => rx_serdesstrobe, |
16 | rx_bufg_pll_x1 => rx_bufg_x1, |
17 | bitslip => bitslip, |
18 | reset => reset, |
19 | datain => clk_iserdes_data, |
20 | rx_bufpll_lckd => rx_bufpll_lckd |
21 | );
|
22 | |
23 | not_bufpll_lckd <= not rx_bufpll_lckd ; |
24 | |
25 | datain : serdes_1_to_n_data_s8_diff |
26 | generic map( |
27 | S => S, |
28 | D => D |
29 | )
|
30 | port map ( |
31 | use_phase_detector => '1', |
32 | datain_p => datain_p, |
33 | datain_n => datain_n, |
34 | rxioclk => rx_bufpll_clk_xn, |
35 | rxserdesstrobe => rx_serdesstrobe, |
36 | gclk => rx_bufg_x1, |
37 | bitslip => bitslip, |
38 | reset => not_bufpll_lckd, |
39 | debug_in => "00", |
40 | data_out => rxd, |
41 | debug => open |
42 | );
|
Nun könnte ich mir gut vorstellen, dass sich was in der Statemachine aufhängt, wenn dies an einer ungünstigen Stelle passiert - oder es kommt zu irgend einem deadlock oder so... Da müßte ich mich mal noch tiefer in das Template von Xilinx reinarbeiten. Bisher habe ich es "nur benutzt" bzw. konfiguriert, wie es in der XAPP1064 beschrieben ist. Morgen werden einige Tests beim Kunden vor Ort durchgeführt (bereits mit korrekt eingestelltem Speed Grade...). Mal sehen, was diese Tests zeigen. Ich habe auch noch einige Debug-Möglichkeiten eingebaut, mit denen ich von dem MicroBlaze aus an einigen Reset-Leitungen ziehen kann. Ich bin gespannt, welches Modul konkret zurück gesetzt werden muss, damit es wieder läuft... Falls Ihr noch Ideen habt: bitte mitteilen. DANKE! Ansonsten melde ich mich wieder, wenn ich mehr weiß Viele Grüße, Andreas
Hast du bei dir im Labor einen Temperatur-Test gemacht?
SuperWilly schrieb: > Hast du bei dir im Labor einen Temperatur-Test gemacht? Hallo SuperWilly, danke für Deine Antwort! Ja, ich habe die ganze Leiterplatte und vor allem natürlich das FPGA sowohl mit Kältespray, als auch mit einem Heißluftfön gequält. --> leider konnte ich auch so den Fehler nicht reproduzieren... Viele Grüße, Andreas
OK, wie sieht es mit der Spannungsversorgung (vor allem FPGA-Core-Spannung) aus? Kann die u.U. einen kritischen Wert unterschreiten?
SuperWilly schrieb: > OK, wie sieht es mit der Spannungsversorgung (vor allem > FPGA-Core-Spannung) aus? Kann die u.U. einen kritischen Wert > unterschreiten? Naja, "eigentlich" würde ich das ausschliessen. Die Spannungen werden auf dem Modul generiert: http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE0600-GigaBee_series/TE0600/documents/SCH-TE0600-01.pdf Versorgt wird es über 3,3V, die von einem DC/DC Wandler kommen. Bei meinen EMV-Tests im Labor, ist hier keine Auffälligkeit aufgetreten. Im Gegenteil: Selbst massive Spannungsschwankungen (verursacht durch das Labornetzteil) führten zu keinen Fehlern im FPGA. Es ist wirklich seltsam. Da läuft ein Frequenzumrichter in der Nähe meines Geräts. Wenn dieser an ist und ein Förderband mitläuft (welches wahrscheinlich zu elektrostatischen Entladungen neigt...), dann tritt der Fehler auf. ABER: Mein Gerät ist NICHT elektrisch mit dem Förderband o.ä. verbunden. Wenn überhaupt, dann kommt die Störung über die Luft, oder über die Masse rein. :-( Viele Grüße, Andreas
Wo kommt der Takt her? Wenn der von der DCM kommt, kann sein, dass DCM sich aufhängt. Da hilft mit einem "langsamen" Takt "locked"-Signal zu überwachen.
♪Geist schrieb: > Wo kommt der Takt her? Wenn der von der DCM kommt, kann sein, dass DCM > sich aufhängt. Da hilft mit einem "langsamen" Takt "locked"-Signal zu > überwachen. Hallo, der Clock kommt (indirekt) von einem Quarzoszillator von KYOCERA KC7050Y250.000P30EZU. Der Quarzoszillator geht auf den A/D-Wandler. Und vom A/D-Wandler kommen dann sowohl Clock, als auch die Daten zum FPGA. Viele Grüße, Andreas
Kannst du vor Ort ein Augendiagramm aufnehmen? Vielleicht ist es schon relativ geschlossen, so dass es in einer rauhen Umgebung kurzzeitig "geschlossen" wird. (Hilft es die "pre-emphasis" zu ändern?) Kannst Du die Auswirkungen von Ground-Bouncing schaltungstechnisch reduzieren?
Der Spartan 6 DCM/PLL ist ja etwas eigenwillig im Reset-Verhalten, vielleicht liegts daran? Da gibts im Clocking User Guide ein Kapitel über das richtige zurücksetzen bei Störung...
SuperWilly schrieb: > Kannst du vor Ort ein Augendiagramm aufnehmen? > Vielleicht ist es schon relativ geschlossen, so dass es in einer rauhen > Umgebung kurzzeitig "geschlossen" wird. > (Hilft es die "pre-emphasis" zu ändern?) > > Kannst Du die Auswirkungen von Ground-Bouncing schaltungstechnisch > reduzieren? Hallo SuperWilly, wenn ich KURZZEITIG keine oder korrupte Daten bekommen würde, dann wäre alles plausibel und verständlich. Problem ist aber, dass ich nach der Störung ausschließlich Nullen bekommen - bis ich das SERDES-Modul zurück setze. Vor Ort kann ich das Augendiagramm leider nicht aufnehmen (lassen)... > Andere SMA-Kabel ausprobiert? :-) Das wirklich "magische" ist ja, dass es reicht, eine 30cm kurze SMA-Leitung anzuschließen, die auf der anderen Seite OFFEN ist. > Der Spartan 6 DCM/PLL ist ja etwas eigenwillig im Reset-Verhalten, > vielleicht liegts daran? Da gibts im Clocking User Guide ein Kapitel > über das richtige zurücksetzen bei Störung... Ich werde mir das Kapitel mal anschauen. Was denkst Du: Wäre es möglich, dass ein gestörter DCM/PLL den SERDES so "durchschütteln" kann, dass nur noch Nullen kommen? --> Ich hätte halt erwartet, dass in so einem Fall GAR KEINE Daten mehr kommen... Viele Grüße, Andreas
Andreas N. schrieb: > Was denkst Du: > Wäre es möglich, dass ein gestörter DCM/PLL den SERDES so > "durchschütteln" kann, dass nur noch Nullen kommen? Wenn der in den "Nicht-Locked" Zustand geht und dann dort verharrt, ja. Andreas N. schrieb: > Das wirklich "magische" ist ja, dass es reicht, eine 30cm kurze > SMA-Leitung anzuschließen, die auf der anderen Seite OFFEN ist. Hast du denn die DIFFTERM an den Eingängen auf TRUE gesetzt? Beim Clock auch?
Andreas N. schrieb: > Das wirklich "magische" ist ja, dass es reicht, eine 30cm kurze > SMA-Leitung anzuschließen, die auf der anderen Seite OFFEN ist. hi andreas, ohne von dem, was du da treibst, irgendeine ahnung zu haben: ein 30 cm langes leitungsstück ohne abschluss (also "offen") kann auf jeden fall bei den genannten frequenzen einen satten kurzschluss bewirken und ist ein absolutes no-no an den daten- oder clk leitungen. das musst du auch deinem klienten verklickern. hol dir input von einem HF- spezialisten zu diesem problem, stichwörter sind "wellenwiderstand", "stichleitung". das ist nix magisches, das ist einfach nur hochfrequenztechnik ;o) viel glück! hans
Nun, da die 30cm Leitung wohl das Problem darstellt, kann es nur etwas Analoges sein. Ich sehe das auch kritisch, dass dort "offene" Leitungen angeschlossen werden, ... .. aber ist das überhaupt so? Die Leitung wird doch sicher niederohmig getrieben, nehme ich mal an. Wenn die umgeschaltet, umgesteckt oder oder sind wie kurz offen ist, wäre das ein klassisches hot plug Problem und damit nicht das Deinige :-)
hans schrieb: > Andreas N. schrieb: >> Das wirklich "magische" ist ja, dass es reicht, eine 30cm kurze >> SMA-Leitung anzuschließen, die auf der anderen Seite OFFEN ist. > > hi andreas, ohne von dem, was du da treibst, irgendeine ahnung zu haben: > ein 30 cm langes leitungsstück ohne abschluss (also "offen") kann auf > jeden fall bei den genannten frequenzen einen satten *kurzschluss* > bewirken und ist ein absolutes no-no an den daten- oder clk leitungen. > das musst du auch deinem klienten verklickern. > hol dir input von einem HF- spezialisten zu diesem problem, stichwörter > sind "wellenwiderstand", "stichleitung". das ist nix magisches, das ist > einfach nur hochfrequenztechnik ;o) > viel glück! > hans Hallo Hans, vielen Dank für Deine Antwort. Gaaaanz so schlimm ist es nicht. Ein wenig weiß ich schon über Termination, Wellenwiderstand und Reflexionen auf Leitungen Bescheid... Wenn mein Wissen dazu auch gerne mehr sein dürfte... :-) Zu Deinem Hinweis: Die 30cm Leitung ist der ANALOGE Eingang des A/D-Wandlers. Dort liegt normalerweise das analoge Signal an. Intern habe ich diese Leitung (Eingangsseitig) mit 100 Ohm abgeschlossen. Die digitalen Leitungen des Datenbusses vom A/D-Wandler zum FPGA sind mit relativ schönen, möglichst gleich langen (inkl. Meander) differentiellen LVDS-Pärchen auf der Leiterplatte geroutet. zu den "offenen Leitungen": Dieser Test wurde AUSSCHLIEßLICH zur Fehlereingrenzung gemacht. Ich habe zuerst veranlasst, dass alle 24V-Signale von der SPS entfernt werden. --> Problem trat trotzdem auf. Dann die digitalten Ausgänge von meinem Gerät. --> Problem trat trotzdem auf. Erst dann wurden TESTWEISE die SMA-Leitungen der Analogeingänge entfernt. Nachdem diese Leitungen (inklusive dem Treiber auf der anderen Seite...) nicht an meinem Gerät angeschlossen waren, trat das Problem nicht mehr auf. Dann hat man TESTWEISE eine offene SMA-Leitung angeschlossen --> und das Problem tritt immer noch auf --> es hätte ja auch sein können, dass der Treiber auf der anderen Seite der SMA-Leitung die Ursache ist --> das ist aber nicht der Fall. Es tritt AUCH auf, wenn die 30cm SMA-Leitung auf der zweiten Seite mit 75Ohm (ein anderer Abschlusswiderstand ist gerade nicht verfügbar...) abgeschlossen wird. Und wie gesagt: es ist ja intern immernoch ein 100 Ohm Widerstand gegen Masse angeschlossen. Viele Grüße, Andreas
Angehängte Dateien:
-
Oszillator.jpg
41 KB
Heute wurden weitere Tests gemacht. Ergebnis: 1. Der Speed Grade war NICHT die Ursache (wie weiter oben schon erwartet). 2. Wenn ich die SERDES vor jeder Messung automatisch Resette, dann tritt das Problem nicht auf. Bzw.: Wenn es auftritt, dann ist nur eine einzige Messung betroffen. Bei der nächsten Messung (nach dem nächsten Reset) ist dann wieder alles OK. --> Als Workaround kann ich nun die Plausibilität der Messung überprüfen und ggf. Fehlmessungen ignorieren. Als nächster Schritt wird dann wohl eine saubere Entflechtung anstehen. Ich hoffe, dass dann die Probleme behoben sind. Die Reset-Lösung werde ich dann trotzdem noch aktiv lassen --> so kann ich ausschließen, dass das System in einen "Deadlock" kommt. Ich habe Euch auch ein Bild der wahrscheinlichen Quelle des Irrsinns angehängt. Also ich meine natürlich den 250MHz Oszillator, der zu dem A/D-Wandler gefädelt ist. Und bevor jemand schreit: Ich weiß, dass das ganz schlimm ist und man das nicht machen darf. Aber es ging halt in der kürze der Zeit nicht anders... Und auch wie gesagt: Ich hätte halt mit irgendwelchen Bitfehlern gerechnet - aber nicht mit solch einem "gemeinen" Verhalten... Viele Grüße, Andreas
(Wie) ist dein 250MHz Oszillator terminiert, der in den FPGA geht? Sind die anlogen Leitungen differenziell oder single ended mit GND, dann kann sich der was "ziehen". Kann es sein, dass dein ADC eine eigene PLL hat und die kurzzeitg ausfällt? Dass der SERDES garnichts liefert, ist komisch. Wenn, dann läuft da ein bit über und fällt über den overflow oder es klappt der bit slip nicht. Ist das ein automatisch generierter SERDES? Dort gab es ja schon öfters mal Probleme, wenn das mit CoreGEn gemacht wurde. Besser ist es per Hand die Master-Slave-Kombi zu setzen.
Weltbester FPGA Pongo schrieb im Beitrag #3102585: > (Wie) ist dein 250MHz Oszillator terminiert, der in den FPGA geht? Der ist über die im FPGA integrierten 100 Ohm Widerstände terminiert. Alle differentiellen LVDS Pärchen habe ich so terminiert. In der UCF-Datei: DIFF_TERM = TRUE | IOSTANDARD = LVDS_33 > Sind die anlogen Leitungen differenziell oder single ended mit GND, dann > kann sich der was "ziehen". Die kommen single ended über eine Coax-Leitung an --> das war (leider) eine Vorgabe des Kunden. > Kann es sein, dass dein ADC eine eigene PLL hat und die kurzzeitg > ausfällt? Soweit ich weiß, hat der kein PLL. > Dass der SERDES garnichts liefert, ist komisch. Wenn, dann läuft da ein > bit über und fällt über den overflow oder es klappt der bit slip nicht. Das ist nicht ganz richtig: Der SERDES liefert ja Daten - aber halt nur Nullen. > Ist das ein automatisch generierter SERDES? Dort gab es ja schon öfters > mal Probleme, wenn das mit CoreGEn gemacht wurde. Besser ist es per Hand > die Master-Slave-Kombi zu setzen. Ich habe den nicht über den CoreGen generiert. Ich habe die templates von der XAPP1064 verwendet. Ich habe die zwei Dateien für clk und data mal angehängt. Viele Grüße, Andreas
Andreas N. schrieb: > Als nächster Schritt wird dann wohl eine saubere Entflechtung anstehen. > Ich hoffe, dass dann die Probleme behoben sind. Dann aber möglichst gleich so, dass du die PLL rauswerfen kannst und wie oben geschrieben alles auf einer halbe Bank hast, DCO auf einen GCLK. Dann hast du die wenigsten Probleme und brauchst den ganzen Kladderadatsch nicht.
Hallo Christian, ich befürchte, das ich (aus Zeitgründen) bei dem Xilinx-Modul bleiben werde. Ich werde also "nur" das EVA-Board von ANALOG neu entflechten. Das heißt, ich werde wohl oder übel auch bei dem PLL bleiben müssen. :-( Ich habe mir die Konfiguration (per SPI-Bus) des A/D-Wandlers nochmal angeschaut. Der hat einen DCS (Duty cycle stabilizer) --> dieser ist standardmäßig aktiviert. Auszug aus dem Datenblatt:
1 | A wait time of 1.5 μs to 5 μs is required after a dynamic clock frequency increase or decrease before the DCS loop is relocked to the input signal. |
2 | During the period that the loop is not locked, the DCS loop is bypassed, and internal device timing is dependent on the duty cycle of the input clock signal. |
3 | In such applications, it may be appropriate to disable the duty cycle stabilizer. |
4 | In all other applications, enabling the DCS circuit is recommended to maximize ac performance. |
Ich könnte mal probieren, den DCS zu deaktivieren... Viele Grüße, Andreas
Ich bin nicht davon überzeugt, dass es da überhaupt eine PLL brauchst, trotz der ungünstigen Pinverteilung. Letztendlich sind 250 MHz noch nicht so viel, und ausserdem hast du wegen dem ADC Timing fast 0.5 ns Luft, die die Clock im FPGA verzögert sein darf. (Vorrausgesetzt durch das Boardlayout gibt es keinen Skew) Auch 1:8 Gearing ist deswegen Overkill. Auf der Analog webseite gibt es für den AD9643 Sample code (na gut in Verilog statt VHDL). ftp://ftp.analog.com/pub/HSSP_SW/fpga/AD9643_data_capture_rtl.zip Da wird direkt ein IDDR instanziert, wie das in VHDL geht siehst du hier: Beitrag "Generic Map IDDR"
Thread beobachten
Seitenaufteilung abschaltenBitte 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.