Hallo liebes Forum, ich benutze folgenden Buffer um eine 150MHz Clock (@2.5V) zu treiben: (Hatte mich in meinem ursprünglichen Post vertan, nun steht hier der richtige Buffer!!!) sn74avc8t245 http://www.ti.com/lit/ds/symlink/sn74avc8t245.pdf Die Clock kommt von einem FPGA mit 2.5V. Der Buffer selbst hat für VCCA+VCCB jeweils 1.8V zur Verfügung => Ich möchte die 2.5V Input zusätzlich auf 1.8V drücken. Mein Problem: Am Ausgang des Buffers (welchen ich aktuell nicht mit dem Receiver verbunden habe), werden zwar die 1.8V erreicht, allerdings komme ich bei der LOW-Time des Signals nicht auf 0V, der Buffer kommt nur auf fast 1V runter, was meinen Receiver völligst verrückt macht :/ (siehe Anhang) Außerdem ist das Ausgangssignal generell etwas verschliffen. Woran kann das liegen?
Angehängte Dateien:
-
Buffer_input.png
320 KB -
buffer_output.png
260 KB -
input_output.png
470 KB
:
Bearbeitet durch User
full well schrieb: > Ich möchte die 2.5V Input > zusätzlich auf 1.8V drücken. full well schrieb: > Woran kann das liegen? > Max Data Rates > 75 Mbps (translate to 1.8 V)
Angehängte Dateien:
-
input_output.png
470 KB
Hatte mich leider vertan! Habe es in dem Eingangspost nun auch geändert... Es handelt sich um diesen Buffer SN74AVC8T245 http://www.ti.com/lit/ds/symlink/sn74avc8t245.pdf Soeben habe ich noch festgestellt das das Signal auch gedreht ist...Siehe Anhang.
:
Bearbeitet durch User
@ full well (realjey) >ich benutze folgenden Buffer um eine 150MHz Clock (@2.5V) zu treiben: du dich byen Deutschbox. >Die Clock kommt von einem FPGA mit 2.5V. Der Buffer selbst hat für >VCCA+VCCB jeweils 1.8V zur Verfügung => Ich möchte die 2.5V Input >zusätzlich auf 1.8V drücken. Nennt sich Pegelwandler. >Am Ausgang des Buffers (welchen ich aktuell nicht mit dem Receiver >verbunden habe), werden zwar die 1.8V erreicht, allerdings komme ich bei >der LOW-Time des Signals nicht auf 0V, der Buffer kommt nur auf fast 1V >runter, was meinen Receiver völligst verrückt macht :/ (siehe Anhang) >Außerdem ist das Ausgangssignal generell etwas verschliffen. Wie hast du das gemessen? Was für ein Tastkop, was für ein Oszi? Masseanbindung? Die endliche Bandbreite des ICs wurde ja schon genannt.
@ full well (realjey) > input_output.png >Hatte mich leider vertan! Habe es in dem Eingangspost nun auch >geändert... Weder das Eingangssignal noch das Ausgangssignal haben etwas mit einem Takt zu tun. >SN74AVC8T245 >http://www.ti.com/lit/ds/symlink/sn74avc8t245.pdf >Soeben habe ich noch festgestellt das das Signal auch gedreht >ist...Siehe Anhang. Schon mal was von einer Phasenverschiebung gehört? Und einer Gatterlaufzeit? 150 MHz sind ~6ns periodendauer. Bei 1,8V hat der IC aber typ. 2,5ns Gatterlaufzeit. Dazu kommen deine massiven Meßfehler.
Falk Brunner schrieb: > Wie hast du das gemessen? Was für ein Tastkop, was für ein Oszi? > Masseanbindung? Oszi: Lecroy Waverunner 625Zi Tastkopf 10:1, 500MHz, 1MOhm, 9.5pF Masseanbingung rel. nahe am Chip...ca. 3cm Massekabel an die Platine gelötet. Falk Brunner schrieb: > Die endliche Bandbreite des ICs wurde ja schon genannt. Habe es korrigiert, die Bandbreite sollte kein Problem sein oder?
Falk Brunner schrieb: > Schon mal was von einer Phasenverschiebung gehört? Und einer > Gatterlaufzeit? Ja :) > 150 MHz sind ~6ns periodendauer. Bei 1,8V hat der IC aber typ. 2,5ns > Gatterlaufzeit. Dazu kommen deine massiven Meßfehler. a) OK, dann sollte die Ausgangsspannung aber doch nicht um 180° verschoben sein oder? Welche Meßfehler meinst du genau? Danke...
An dem Buffer sind noch 3 weitere Signale, allerdings im KHz-Bereich. 2.5V Eingangspegel am Buffer, 1.8V Ausgangspegel. Diese machen keine Probleme und lassen sich mit dem beschriebenem Messequipment einwandfrei auf Richtigkeit verifizieren. Es muss also schon etwas mit der 'hohen' Frequenz zu tun haben, so meine Vermutung... Was könnte das Problem für den Buffer sein?
:
Bearbeitet durch User
@ full well (realjey) >Oszi: Lecroy Waverunner 625Zi Bandbreite? OK, LeCroy sagt 2,5GHz. >Tastkopf 10:1, 500MHz, 1MOhm, 9.5pF MÖÖP! So nicht. Auch wenn dort 500 MHz draufstehen, kann man 500 MHz nicht WIRKLICH damit messen. 10pF haben bei 500 MHz noch 32 OHM!!! >Masseanbingung rel. nahe am Chip...ca. 3cm Massekabel an die Platine >gelötet. Suboptimal, für sowas MUSS man eine Massefeder (aka. ground spring) nutzen, damit man auf 10mm und weniger kommt. Wenn man einen 150 MHz TAKT, der ja ein wenig rechteckig aussehen soll, messen will, braucht man entweder einen aktiven Tastkopf mit mind. 1 GHz oder einen passiven Z0-Tastkopf mit 1-2kOhm. Wenig Eingangskapazität ist hier alles! 1pF und weniger! >> Die endliche Bandbreite des ICs wurde ja schon genannt. >Habe es korrigiert, die Bandbreite sollte kein Problem sein oder? Sie ist auch hier grenzwertig, sollte aber gerade noch gehen. Aber ohne gescheite Messung wirst du das nie herausfinden. https://www.mikrocontroller.net/articles/Oszilloskop#Tastk.C3.B6pfe_richtig_benutzen http://www.signalintegrity.com/Pubs/straight/probes.htm
@ full well (realjey) >> 150 MHz sind ~6ns periodendauer. Bei 1,8V hat der IC aber typ. 2,5ns >> Gatterlaufzeit. Dazu kommen deine massiven Meßfehler. >a) OK, dann sollte die Ausgangsspannung aber doch nicht um 180° >verschoben sein oder? Oder. >Welche Meßfehler meinst du genau? Falscher Tastkopf, zu lange Masseverbindung.
Falk Brunner schrieb: > Falscher Tastkopf, zu lange Masseverbindung. OK, habe ich aber nicht da und werde ich auf die Schnelle auch nicht auftreiben können... Falk Brunner schrieb: >>a) OK, dann sollte die Ausgangsspannung aber doch nicht um 180° >>verschoben sein oder? > > Oder. OK, bei 2.5ns passt das mit der Verschiebung um eine halbe Periode wohl doch ganz gut...oder? :) Das würde mir garnichts machen, da ja die anderen 3 Signale (welche synchron zur CLOCK sein müssen), die gleiche Gaterlaufzeit besitzen, also am Ausgang wieder synchron sein sollten. Allerdings, egal ob Messfehler oder nicht, kann mein Receiver (CMOS-Sensor), die 150MHz-CLOCK nicht erkennen. Wenn ich aber die CLOCK direkt vom FPGA an den Receiver anschliesse, ohne Buffer, dann funktioniert das. Es ist also davon auszugehen, das das Problem darin liegt, dass die CLOCK nicht mehr auf NULL runter geht, egal wie genau das jetzt gemessen ist. Also nochmal: Woran kann es liegen, das der Buffer dieses Verhalten zeigt und wie könnte ich hier weiter vorgehen? MfG
@ full well (realjey) >> Falscher Tastkopf, zu lange Masseverbindung. >OK, habe ich aber nicht da und werde ich auf die Schnelle auch nicht >auftreiben können... Selber bauen. 2m RG174, 1k Widerstand, BNC Stecker. >Das würde mir garnichts machen, da ja die anderen 3 Signale (welche >synchron zur CLOCK sein müssen), Es heißt DER TAKT!!! > die gleiche Gaterlaufzeit besitzen, >also am Ausgang wieder synchron sein sollten. Warum braucht man einen 150 MHz Takt, um kHz Signale zu übermmitteln? >Allerdings, egal ob Messfehler oder nicht, kann mein Receiver >(CMOS-Sensor), die 150MHz-CLOCK nicht erkennen. Es ist ein 150 MHz Takt und kein 150 MHZ-Clock. >Es ist also davon auszugehen, das das Problem darin liegt, dass die >CLOCK nicht mehr auf NULL runter geht, egal wie genau das jetzt gemessen >ist. Reines Raten. >Also nochmal: Woran kann es liegen, das der Buffer dieses Verhalten >zeigt und wie könnte ich hier weiter vorgehen? Wurde schon mehrfach gesagt. Mach eine ordentliche Messung! Trotzdem glaube ich, dass du mit dieser Schaltung überfordert bist. 150 MHz Takt ist kein Kindergeburtstag mehr. Das ist schon richtige HF.
Falk Brunner schrieb: >>> Falscher Tastkopf, zu lange Masseverbindung. > >>OK, habe ich aber nicht da und werde ich auf die Schnelle auch nicht >>auftreiben können... > > Selber bauen. 2m RG174, 1k Widerstand, BNC Stecker. Kannst du mir das noch einmal genauer erklären bitte?! Wenn ich alle Bauteile da habe, schließe ich über den BNC-Stecker das Kabel an mein Oszi. Dannn kommt der 1k dann in Reihe zum Kabel und bildet gleichzeitig meine Messspitze oder wie ist das gemeint? Falk Brunner schrieb: >>Das würde mir garnichts machen, da ja die anderen 3 Signale (welche >>synchron zur CLOCK sein müssen), > > Es heißt DER TAKT!!! Beruhige dich, ich kann auch gerne "der Takt" schreiben, kein Problem... Falk Brunner schrieb: >> die gleiche Gaterlaufzeit besitzen, >>also am Ausgang wieder synchron sein sollten. > > Warum braucht man einen 150 MHz Takt, um kHz Signale zu übermmitteln? Es sind einfach 4 verschiedene Signale/Takte,welche synchron am Receiver (sorry Empfänger) ankommen müssen. Das zwischen diesen Signalen so große Frequenzunterschiede sind, liegt einfach an der Art wie der Empfänger betrieben werden muss (CMOS-Sensor mit MCLK (150MHz), LINE_SYNC, FRAME_SYNC etc.) Falk Brunner schrieb: >>Also nochmal: Woran kann es liegen, das der Buffer dieses Verhalten >>zeigt und wie könnte ich hier weiter vorgehen? > > Wurde schon mehrfach gesagt. Mach eine ordentliche Messung! Werde ich probieren. Aber eine Vorab-Idee was hier den Fehler verursachen könnte, wäre trotzdem schön ;) Falk Brunner schrieb: > Trotzdem glaube ich, dass du mit dieser Schaltung überfordert bist. 150 > MHz Takt ist kein Kindergeburtstag mehr. Das ist schon richtige HF. Richtig, dieser Schaltungsteil macht mir Probleme und ich komme nicht weiter. Deswegen bin ich hier! Also falls du (oder jemand anders) noch eine Idee hat, warum mein Taktpuffer nicht in der Lage ist auf 0V zu kommen, wäre das super. Ne generelle Frage: Kann mir jemand nen Takt-Puffer empfehlen, welcher ohne Probleme in der Lage ist 150MHz zu puffern und gleichzeitig eine Pegelwandlung von 2.5V auf 1.8V vollziehen kann? MfG
@ full well (realjey) >> Selber bauen. 2m RG174, 1k Widerstand, BNC Stecker. >Kannst du mir das noch einmal genauer erklären bitte?! Seite lesen! http://www.signalintegrity.com/Pubs/straight/probes.htm >Wenn ich alle Bauteile da habe, schließe ich über den BNC-Stecker das >Kabel an mein Oszi. Dannn kommt der 1k dann in Reihe zum Kabel und >bildet gleichzeitig meine Messspitze oder wie ist das gemeint? Genau so. >Es sind einfach 4 verschiedene Signale/Takte,welche synchron am Receiver >(sorry Empfänger) ankommen müssen. Das zwischen diesen Signalen so große >Frequenzunterschiede sind, liegt einfach an der Art wie der Empfänger >betrieben werden muss (CMOS-Sensor mit MCLK (150MHz), LINE_SYNC, >FRAME_SYNC etc.) OK. Aber auch dann müssen diese, trotz ihrer vermeintlich niedrigen Frequenz, eine definierte Phasenlage zum Takt haben. Sonst funktioniert es nicht. >Werde ich probieren. Aber eine Vorab-Idee was hier den Fehler >verursachen könnte, wäre trotzdem schön ;) Möglicherweise ist deine Verbindung zwischen FPGA und Sensor nicht HF-tauglich, siehe Wellenwiderstand. Und da du es ja anscheinend mit 2,5V schon probiert hast und es funktionierte, warum dann der Aufwand mit 1,8V? Vielleicht verträgt der Sensor direkt 2,5V Eingangssignale, siehe Pegelwandler. >Ne generelle Frage: Kann mir jemand nen Takt-Puffer empfehlen, welcher >ohne Probleme in der Lage ist 150MHz zu puffern und gleichzeitig eine >Pegelwandlung von 2.5V auf 1.8V vollziehen kann? Selbst mit dem tollsten IC musst du das Ergenis verifizieren, sprich messen können.
kannst du auch mal eine Flanke auf einem der "langsamen" Buffer Ausgänge messen, aber mit der selben Zeitauflösung wie den Takt (also 20ns/DIV)? Hängt am Buffer-Ausgang eine längere Leitung? Falls ja: wie sieht die aus (Leitungstopologie, Länge, Impedanz) und an welchem Ende der Leitung hast du gemessen?
Angehängte Dateien:
-
MCLK_zu_LINE_SYNC.png
300 KB
Falk Brunner schrieb: > Selber bauen. 2m RG174, 1k Widerstand, BNC Stecker. Leider habe ich nur RG58C gefunden. Muss ich bis nächste Woche warten. Hat es einen bestimmten Grund warum du 2m vorschlägst? Falk Brunner schrieb: > OK. Aber auch dann müssen diese, trotz ihrer vermeintlich niedrigen > Frequenz, eine definierte Phasenlage zum Takt haben. Sonst funktioniert > es nicht. Nunja, alle anderen Takte/Signale sind auf MCLK (der 150MHz-Takt), d.h. im FPGA sind die 150MHz der Master-Takt und alle anderen Takte davon abgeleitet. Die Phasenlage ist also definiert. Achim S. schrieb: > kannst du auch mal eine Flanke auf einem der "langsamen" Buffer Ausgänge > messen, aber mit der selben Zeitauflösung wie den Takt (also 20ns/DIV)? Messungen im Anhang: MCLK (150MHz) zu LINE_SYNC (72kHz aber nur ein Puls zu sehen)...Direkt nach dem Buffer gemessen. Auch hier zu sehen, das MCLK weder die 1.8V erreicht, noch bis runter auf NULL geht. Die Richtigkeit der Messung wurde aber verständlicherweise angezweifelt :) Achim S. schrieb: > Hängt am Buffer-Ausgang eine längere Leitung? Falls ja: wie sieht die > aus (Leitungstopologie, Länge, Impedanz) und an welchem Ende der Leitung > hast du gemessen? Die Leitung bis zum Empfänger sind 30mm. Die Messungen sind direkt hinter dem Buffer gemessen. Am Empfänger sehen sie aber identisch aus.
:
Bearbeitet durch User
@ full well (realjey) >Leider habe ich nur RG58C gefunden. Geht auch, ist aber deutlich dicker und steifer, damit hat man praktisch nicht viel Spaß. >Hat es einen bestimmten Grund warum du 2m vorschlägst? Einfach so. Du kannst auch 1m oder weniger nehmen, musst dann aber deine Schaltung recht nah an dein Oszi packen. >Nunja, alle anderen Takte/Signale sind auf MCLK (der 150MHz-Takt), d.h. >im FPGA sind die 150MHz der Master-Takt und alle anderen Takte davon >abgeleitet. Die Phasenlage ist also definiert. Ja, aber du kannst es nicht sinnvoll messen. Dein Bild beweist das! >Messungen im Anhang: MCLK (150MHz) zu LINE_SYNC (72kHz aber nur ein Puls >zu sehen)...Direkt nach dem Buffer gemessen. Auch hier zu sehen, das >MCLK weder die 1.8V erreicht, noch bis runter auf NULL geht. Hier ist glaube ich entweder der Treiber oder dein Tastkopf massiv am Anschlag. Ist dein Tastkopf zufällig auf 1:1 umschaltbar und auch darauf eingestellt? Hier stimmt einiges nicht. Das ist keine Messung, nicht mal eine Schätzung! Hat dein Treiber einen Entkoppelkondensator NAH am IC? Poste mal ein Bild vom Aufbau/Layout unter Beachtung der Bildformate.
Angehängte Dateien:
-
Schematic_Buffer.png
68 KB -
Layout_Buffer.png
250 KB
Falk Brunner schrieb: > Hier ist glaube ich entweder der Treiber oder dein Tastkopf massiv am > Anschlag. Ist dein Tastkopf zufällig auf 1:1 umschaltbar und auch darauf > eingestellt? Hier stimmt einiges nicht. Das ist keine Messung, nicht mal > eine Schätzung! Zmd. nicht das ich es wüsste ;)..Sind die beim Oszi mitgelieferten von Lecroy:PP008 Falk Brunner schrieb: > Hat dein Treiber einen Entkoppelkondensator NAH am IC? Poste mal ein > Bild vom Aufbau/Layout unter Beachtung der Bildformate. Ja zmd an VCCB. An VCCA ist keiner direkt am Pin, könnte ich aber nachsetzen. Es ist nur die Brücke für 1.8V bestückt (logischerweise). Habe übrigens spaßeshalber mal einen anderen Treiber benutzt: ICS621 https://www.idt.com/document/dst/621-datasheet Der schafft es ohne Probleme, selbst ohne Leitungsterminierung...zmd. läuft mein Empfänger und die Oszi-Messung sieht akzeptabel aus... Allerdings wäre es deutlich schöner diese Platine benutzen zu können ohne noch andere Treiber drauf zu löten, sprich wenn ich den sn74avc8t245 zum laufen bekommen würde, wäre das genial!
:
Bearbeitet durch User
Wo misst du denn EXAKT? Direkt am IC? Oder doch hinter den Widerständen? Vielleicht ist aus Versehen ein falscher Widerstandswert bestückt worden? Oder es gibt eine kalte Lötstelle beim Takt?
Ach ja, das mit dem Signal SO und SO_out klappt nicht wirklich, denn das geht in die andere Richtung!
Falk Brunner schrieb: > Wo misst du denn EXAKT? Direkt am IC? Oder doch hinter den Widerständen? > Vielleicht ist aus Versehen ein falscher Widerstandswert bestückt > worden? Oder es gibt eine kalte Lötstelle beim Takt? Die Messung die ich angehangen habe ist am Pad für den Widerstand gemessen. Aber auf der Seite des Ausgangs des Treibers, also quasi direkt am Treiber... Falk Brunner schrieb: > Ach ja, das mit dem Signal SO und SO_out klappt nicht wirklich, denn das > geht in die andere Richtung! Doch das klappt, ist eventuell mißverständlich gezeichnet. SO befindet sich auf der Empängerplatine und wird bis zum FPGA, über den Treiber, geführt. Geht also in die andere Richtung, am Treiber aber identische Richtung: SO kommt vom Empfänger und geht an den Input des Treibers, SO_out (Ausgang des Treibers) wird dann über das Flachbandkabel an den FPGA geführt...
@ jey (Gast) >Doch das klappt, ist eventuell mißverständlich gezeichnet. SO befindet >sich auf der Empängerplatine und wird bis zum FPGA, über den Treiber, >geführt. Geht also in die andere Richtung, am Treiber aber identische >Richtung: SO kommt vom Empfänger und geht an den Input des Treibers, >SO_out (Ausgang des Treibers) wird dann über das Flachbandkabel an den >FPGA geführt... Das widerspricht aber dem Thema Pegelwandung 2,5V -> 1,8V!!! Denn hier würde ja ein 1,8V auf der Seite A eingespeist und mit ebenso 1,8V wieder ausgegeben.
Falk Brunner schrieb: > Das widerspricht aber dem Thema Pegelwandung 2,5V -> 1,8V!!! > Denn hier würde ja ein 1,8V auf der Seite A eingespeist und mit ebenso > 1,8V wieder ausgegeben. Korrekt, SO hängt aber an ner anderen IO-Bank am FPGA, die mit 1.8V versorgt wird.
jey schrieb: > Korrekt, SO hängt aber an ner anderen IO-Bank am FPGA, die mit 1.8V > versorgt wird. Falk Brunner müsste jetzt sagen es heißt nicht "IO-Bank am FPGA" sondern "Ein-/Ausgabereihe an der Feld programmierbaren Gatter Matrix"
Das Layout ... aaaahhhhhhh ... alles maximal falsch. Das ist vielleicht gut fuer 5MHz oder so. aber sicher nicht fuer 150MHz. Sorry... zum Schema. Die Speisung mit einem 10uF Elko und einem 100nF gepuffert, ist gut fuer einen AVR bei 5MHz. Aber sicher nich fuer 150MHz. flupp ... alles in die Tonne. So wird das nie was. Da liegen noch Welten dazwischen.
Das Layout ist vielleicht nicht das hübscheste. Einen Kondensator direkt an VCCA (statt über die Lötbrücke) würde ich auf jeden Fall nachrüsten, eine durchgehende Massefläche sollte vorhanden sein (und ist auf dem Layoutschnipsel hoffentlich nur der besseren Lesbarkeit wegen nicht gezeichnet). Den Leitungsstub an Sys_clk zum Testpunkt hin hätte ich mir auch gespart, und ich würde keine 3,3V Signale auf den Eingang geben, wenn VCC 1,8V beträgt (selbst wenn der IO das abkann, verzerrt es gewaltig den Duty-Cycle des CLK Signals.) Aber bei <5cm Leitungslänge und bei Anstiegszeiten im Bereich 3ns (genauer Wert unbekannt, weil es die Messung nicht hergibt) glaube ich eher daran, dass wirklich der Treiber zu schlapp ist und dass sich das auch durch ein besseres Layout nicht grundsätzlich verbessern lassen würde. @full well: dass deine Messungen nicht wirklich aussagekräft sind, ist ja schon klar geworden. Bei (fast) jeder deiner einzelnen Messungen hat das CLK Signale eine andere Waveform, was dafür spricht, dass die Messung nicht nur "zu langsam" ist sondern auch nicht reproduzierbar (und einige cm GND-Kabel können da halt einen riesigen Unterschied machen). Aber du kratzt offensichtlich auch an der Grenze deines Bausteins: die 320Mbps, die er bei Vcc>1,8V können soll, entsprechen einer 160MHz CLK mit 50% Duty Cycle. Du hast 150MHz aber einen deutlich größeren Duty Cycle, weil du den 1,8V Eingang mit 3,3V Signalen betreibst. Die "bitzeit" für den Lowpuls ist damit deutlich kleiner 1/320MHz=3,1ns, und demensprechend erreicht der Ausgang nicht den low-level. Außerdem liefert der Ausgang irgendwas um 10mA, die Kapazität des IOs selbst beträgt 7pF, die Schaltung (und bei der Messung auch der Tastkof) liefern jeweils eine zusätzliche Kapazität im Bereich einiger pF: selbst im optimalen Fall kannst du bei dem Treiber und der Last nicht viel mehr als ein Dreieck als CLK erwarten.
Falk Brunner schrieb: >>Wenn ich alle Bauteile da habe, schließe ich über den BNC-Stecker das >>Kabel an mein Oszi. Dannn kommt der 1k dann in Reihe zum Kabel und >>bildet gleichzeitig meine Messspitze oder wie ist das gemeint? > > Genau so. Unerwähnt blieb aber, dass der Oszi-Eingang dann auf 50Ω geschaltet werden muss. jey schrieb: > wird dann über das Flachbandkabel an den > FPGA geführt... Mir sind die Serienwiderstände am Buffer-Ausgang zu klein gewählt, insbesondere wenn plötzlich auch noch ein Flachbandkabel ins Spiel kommt. Wie viele Masseleitungen hast du denn auf dem Flachbandkabel spendiert? Liegen da auch welche direkt neben der Taktleitung?
Das Oszilloskop muss für die Z0 Probe übrigens auf 50R Eingangsabschluss eingestellt sein.
Angehängte Dateien:
-
RG58C.jpg
170 KB -
Buffer_Input.png
290 KB -
Buffer_ouput.png
230 KB
Zur Messung: Ich habe jetzt ein RG-58C/U Kabel genommen und dort einen 1k in Serie gelötet. Das Problem ist allerdings das ich auf den Außenleiter (GND) kein Lötzinn drauf bekomme (dropft immer ab), d.h. ich kann diesen nicht direkt mit GND auf der Platine verbinden. Ich habe mir jetzt mit einem Stück Draht beholfen, welchen ich um den Mantel gewickelt habe und damit gehe ich dann auf das GND der Platine (siehe Anhang). Wahrscheinlich mist?! Jemand einen Tipp für mich, wie ich dieses Problem löse? Wenn ich hiermit messe, sehe ich zwar die Signale auf dem Oszi, allerdings mit sehr niedriger Amplitude (100mV-150mV). Das Oszi ist auf 50-Ohm Kopplung eingestellt. Was mach ich falsch?
:
Bearbeitet durch User
Hat der Treiber echt seine Versorgungsspannung? Alle GND-Pins und OE wirklich festgelötet mit ihren Pads und die wiederum Verbindung mit der Platinenmasse? Irgendwie sieht das nicht so aus. Oder der Chip ist durch oder falschrum eingelötet ;)
full well schrieb: > Das Problem ist allerdings das ich auf den Außenleiter (GND) kein > Lötzinn drauf bekomme (dropft immer ab), d.h. ich kann diesen nicht > direkt mit GND auf der Platine verbinden. ..... > .... Jemand einen Tipp für mich, wie ich dieses Problem löse? Schirm etwas auseinandersortieren, so dass du nur 1/3 der Drähtchen hast. Diese evtl. etwas ankratzen und mit Flussmittel bestreichen, bleihaltiges Lot verwenden und so lange heizen, bis es den Schirm benetzt. full well schrieb: > Das Oszi ist auf > 50-Ohm Kopplung eingestellt. Dein Tastkopf teilt das Signal um einen Faktor 21 (50/1050). Den Faktor musst du in Gedanken an die Kurve dranmultiplizieren.
Achim S. schrieb: > Dein Tastkopf teilt das Signal um einen Faktor 21 (50/1050). Den Faktor > musst du in Gedanken an die Kurve dranmultiplizieren. Kannst du mir bitte erklären wieso hier der Faktor 21 (50/1050)? Ich nehme an durch den 1k-Widerstand ergibt sich ein Spannungsteiler über den Innenwiderstand des Oszis, korrekt? Dann passen die Ergebnisse aber auch nicht wirklich, da am Eingang 3.3V liegen und am Ausgang 1.8V. Ausgang zeigt z.B. ca. 130mV an => 130mV*21=2.7V (ungleich 1.8V)...
:
Bearbeitet durch User
Georg A. schrieb: > Hat der Treiber echt seine Versorgungsspannung? Alle GND-Pins und OE > wirklich festgelötet mit ihren Pads und die wiederum Verbindung mit der > Platinenmasse? Irgendwie sieht das nicht so aus. Oder der Chip ist durch > oder falschrum eingelötet ;) Inbezug darauf muss ich leider sagen, das passt alles :/ So einfach ist es also nicht...
@full well (realjey) >Ich habe jetzt ein RG-58C/U Kabel genommen und dort einen 1k in Serie >gelötet. >Das Problem ist allerdings das ich auf den Außenleiter (GND) kein >Lötzinn drauf bekomme (dropft immer ab), d.h. ich kann diesen nicht >direkt mit GND auf der Platine verbinden. DOCH! Und du MUSST! Nimmt ausreichend Lötzinn und Flußmittel und bitte eine anständig große Lötspitze. Ein von vielen Gründen, warum man hier das deütlich dünnere RG174 nimmt. Oder man kauft gleich einen fertigen Tastkopf, gibt es für 600 Euro bei TEK. P6158: 20X Low Capacitance Probe http://www.tek.com/datasheet/low-capacitance-probe/p6158 > Ich habe mir jetzt mit einem >Stück Draht beholfen, welchen ich um den Mantel gewickelt habe und damit >gehe ich dann auf das GND der Platine (siehe Anhang). Nicht gut! > Wahrscheinlich >mist?! Jemand einen Tipp für mich, wie ich dieses Problem löse? Mit normalem Löten. Und es muss kein Minimelf-Widerstand sein, ein einfacher 1/4 Widerstand reicht und ist mechanisch deutlich günstiger. >Wenn ich hiermit messe, sehe ich zwar die Signale auf dem Oszi, >allerdings mit sehr niedriger Amplitude (100mV-150mV). Das Oszi ist auf >50-Ohm Kopplung eingestellt. Was mach ich falsch? Du hast den Teilerfaktor des Spannungsteilers vergessen. Dein Koaxkabel hat 50 Ohm, der "Vorwiderstand" 1k, macht 50/1050 = 1/21. Kann man auch auf 20 runden, hier geht es nicht um absolute DC-Genauigkeit sondern HF-Eigenschaften. Deine Sihnale sind immer noch grausam, nähern sich aber scheinbar langsam der Realität an. Vor allem das Ausgangssignal sieht schon taktartig aus. Und bei ca. 90mV*21=1,9V. Passt! Und wie man sieht, kommt das Signal sauber bis auf 0V. Dennoch ist hier HF-mäßig noch einiges im Argen. Ich hoffe man stark, dass du auf deiner Platine eine Massefläche hast. Das reicht aber nocht nicht. Das das Signal am Treiber ein Treppenstufe hat, ist bei Serienterminierung normal. Miss mal DIREKT am Empfänger dieses Taktes, dort muss das Signal sauber sein, auch die Flanken.
Erstmal Danke für alle eure Antworten und Tipps! Mit neuen Messungen kann ich leider erst morgen dienen... слюнотечение Тролль schrieb: > zum Schema. Die Speisung mit einem 10uF Elko und einem 100nF gepuffert, > ist gut fuer einen AVR bei 5MHz. Aber sicher nich fuer 150MHz. Das ist auch mein Problem. Ich habe bisher so bis 10MHz-20MHz gearbeitet, da haben meine Designs immer gut funktioniert... Wie bestimme ich den genau den Wert eines Entkoppelkondensators? Welche C-Kombinationen sind für Frequenzen um 150MHz sinnvoll und warum? Kann sie der Elko sogar eher negativ auswirken? Achim S. schrieb: > Das Layout ist vielleicht nicht das hübscheste. Einen Kondensator direkt > an VCCA (statt über die Lötbrücke) würde ich auf jeden Fall nachrüsten, > eine durchgehende Massefläche sollte vorhanden sein (und ist auf dem > Layoutschnipsel hoffentlich nur der besseren Lesbarkeit wegen nicht > gezeichnet) Korrekt, ich habe eine durchgehende, nicht zerschlitze Massefläche auf der Platine. Alle GND-Pads sind über mind. eine VIA so direkt wie möglich auf diese kontaktiert. Desweiteren habe ich auf allen Lagen GND-Polygone welche auch über viele VIAs mit der GND-Plane verbunden sind. Achim S. schrieb: > Aber du kratzt offensichtlich auch an der Grenze deines Bausteins: die > 320Mbps, die er bei Vcc>1,8V können soll, entsprechen einer 160MHz CLK Wieso entsprechen 320Mbps nur 160MHz und nicht 320MHz? Bitte um Erklärung ;) Achim S. schrieb: > Außerdem liefert der Ausgang irgendwas um 10mA, die Kapazität des IOs > selbst beträgt 7pF, die Schaltung (und bei der Messung auch der Tastkof) > liefern jeweils eine zusätzliche Kapazität im Bereich einiger pF: selbst > im optimalen Fall kannst du bei dem Treiber und der Last nicht viel mehr > als ein Dreieck als CLK erwarten. Welchen CLOCK-Treiber kannst du mir empfehlen für die Aufgabe??? Für einen Tipp wäre ich wirklich sehr dankbar. Er muss auch nicht zwingend eine Pegelwandlung machen. Wenn es sein muss, route ich nochmal neu und nehme am FPGA nur 1.8V-IOs für den Takt und die anderen Sensorsignale...
jey schrieb: > Wie bestimme ich den genau den Wert eines Entkoppelkondensators? Welche > C-Kombinationen sind für Frequenzen um 150MHz sinnvoll und warum? App Notes > Kann sie der Elko sogar eher negativ auswirken? Wenn er z.B. sinnvolleren Keramikcaps im Weg steht: Ja. Sonst eher nicht.
jey schrieb: > Wieso entsprechen 320Mbps nur 160MHz und nicht 320MHz? Bitte um > Erklärung ;) 320Mbps bedeuten, dass jedes Bit jeweils 3,13ns lang anliegt. Schau dir die Waveform einer 160MHz Clk an: du hast 3,13ns lang 1, dann 3,13ns lang 0. Du kannst das als CLK mit einer Periode von 6,25ns betrachten. Oder du betrachtest es als übermittlung von zwei Datenbits (immer 1 und darauf folgend 0) mit 3,1ns pro bit. jey schrieb: > Welchen CLOCK-Treiber kannst du mir empfehlen für die Aufgabe??? müsste ich jetzt selbst suchen. Vielleicht kann jemand anders direkt einen passenden aus der Tasche ziehen. Sonst schau ich vielleicht morgen mal, was der Filter bei Digikey oder bei TI so ausspuckt. Was in deiner Schaltung wahrscheinlich schon helfen sollte, ist die Versorgung der High-Pegel Seite mit dem passenden VCC. Wenn du mit einem (verschliffenen) 2,5V Signal auf einen 1,8V Eingang gehst, dann machst du die Low-Phase des Takts künstlich kürzer (denn der Eingang schaltet nicht bei 1,25V in der Mitte des 2,5V Signals sondern bei 0,9V in der Mitte der Versorgung). Vielleicht würden symmetrische Signale dir schon weiter helfen (also Versorgung des Eingangs und Pegel des FPGAs identisch). PS: wenn du ein Re-Routing in Betracht ziehst, kommst du doch eigentlich ganz ohne Treiber aus, oder? Wenn ich es richtig in Erinnerung habe, geht es um eine Punkt zu Punkt Verbindung über 3 cm, das schaffen alles FPGAs, mit denen ich bisher gearbeitet habe ;-)
jey schrieb: > Wie bestimme ich den genau den Wert eines Entkoppelkondensators? Welche > C-Kombinationen sind für Frequenzen um 150MHz sinnvoll und warum? Kann > sie der Elko sogar eher negativ auswirken? Solange es SMD Chipkondensatoren sind, ist der Wert selber nicht so dramatisch. 10nF, 47nF, 100nF oder auch 100nF parallel mit 1nF...10nF sind die gängigen Werte. Und, das Ausgangssignal deines Buffers sieht schon ganz gut aus. Die Haken in der Flanke sind am Leitungsanfang normal. Wenn du am Ende der Leitung misst und diese Leitung auch keine Abzweigungen, Stiche oder mehrere Empfänger hat, dann wirst du dort ein sehr ordentliches Signal sehen können. Außerdem hatte ich weiter oben schon empfohlen, den Widerstand zur Serienterminierung größer zu machen: Nimm eher ca. 30Ω . Du kannst da ein paar Varianten an Werten ausprobieren, um weiter zu optimieren. Der ideale Wert hängt von deiner Platinenimpedanz und vom Innenwiderstand deines Buffers ab. Aber die genannten 30Ω sind erfahrungsgemäß schon recht perfekt. Falk Brunner schrieb: > P6158: 20X Low Capacitance Probe @jey Wenn es wieder Invest gibt, bestelle dir zwei Stück. Ich möchte den nicht mehr missen - einzig will der LeCroy ihn immer als hochohmigen sehen. Das ist aber nicht schlimm - man muss dem Skope nur immer mal bestätigen, dass der Eingang auf 50Ω bleiben soll und man muss den Skalierungsfaktor 20 auch immer wieder (nach dem Einschalten) angeben. Ich verwende die auch zusammen mit einem LeCroy Skope. Damit sind auch Ausgangsspannungen von Schaltreglern viel besser anzuschauen als mit den hochohmigen Standard-Tastköpfen, in die immer nur die Switching Node einstreut.
Achim S. schrieb: > 320Mbps bedeuten, dass jedes Bit jeweils 3,13ns lang anliegt. Schau dir > die Waveform einer 160MHz Clk an: du hast 3,13ns lang 1, dann 3,13ns > lang 0. Du kannst das als CLK mit einer Periode von 6,25ns betrachten. > Oder du betrachtest es als übermittlung von zwei Datenbits (immer 1 und > darauf folgend 0) mit 3,1ns pro bit. Hab deinen Beitrag erst nach Absenden meines gesehen. Mit der Berechnung hast du selbstverständlich recht, aber die Problemen mit schnellen Signalen kommen nicht von der Frequenz, sondern von der Steilheit der Signalflanken - und die sind von der Technologie der eingesetzten Bauteile abhängig. Überschwinger, Doppelflanken usw. gibt es genauso bei einem 10kHz-Takt, der über die selben Baustein geht. Bekämpfbar ist das nicht mit einem schnelleren Treiber (eher nachteilig), sondern mit einer Serienterminierung an der Quelle zusammen mit einer Punkt-zu-Punktverbindung. Achim S. schrieb: > PS: wenn du ein Re-Routing in Betracht ziehst, kommst du doch eigentlich > ganz ohne Treiber aus, oder? Wenn ich es richtig in Erinnerung habe, > geht es um eine Punkt zu Punkt Verbindung über 3 cm, das schaffen alles > FPGAs, mit denen ich bisher gearbeitet habe ;-) Schaffen tun die es schon und gut wird es mit Serienterminierung. Ich wiederhole mich ...
HildeK schrieb: > Mit der Berechnung hast du selbstverständlich recht, aber die Problemen > mit schnellen Signalen kommen nicht von der Frequenz, sondern von der > Steilheit der Signalflanken - und die sind von der Technologie der > eingesetzten Bauteile abhängig. Kein Widerspruch von meiner Seite: full well kann durchaus ein Problem mit der Signalintegrität haben, und das hängt von der Form der Flanken ab, und nicht von der Frequenz. Das gilt jedenfalls wenn die Periode groß ist gegenüber der Anstiegszeit, aber diese Frage war zu dem Zeitpunkt, als ich den 320Mbps-Treiber ins Visier nahm, noch nicht klar. In den bis dahin vorliegenden Messungen war die CLK ein Dreieck, dass nicht annähernd auf den lowpegel runterkam, und full well hat ursprünglich nach der Ursache dieser Signalform gefragt. Ich bin auch bei dir, was die Interpretation der mit dem neuen Tastkopf gemessenen Signalform angeht. Vielleicht macht der Stub zum Testpunkt noch ein bisschen Ärger mit der Signalform am Leitungsende, aber eigentlich deutet in dieser Messung am Leitungsanfang nichts mehr auf ein heftiges Problem der Signalintegrität hin. (so gesehen dürfte die Schaltung ja funktionieren, was sie leider nicht tut.) Viel Reserve hat der 320Mbps Buffer bei der 150 MHz CLK jedenfalls nicht. Außerdem verzieht sich full well den Duty Cycle durch die falsche Kombination von IO-Pegel und Versorgung des Treibereingangs. Vielleicht macht sein Empfänger am Leitungsende ja in Wirklichkeit Probleme wegen des krummen duty cycles der CLK (oder wegen der damit einhergehenden verschobenen Setup-Hold Zeiten).
Angehängte Dateien:
-
Tastkopf_RG174.png
1000 KB -
Probe_Settings.png
400 KB -
FPGA_out.png
270 KB -
Nach_Kabel_vor_33R.png
260 KB -
Buffer_Input_nach_33R.png
260 KB -
Buffer_Output_vor_33R.png
240 KB -
Buffer_Output_nach_33R.png
260 KB -
Direkt_am_Sensor_Pin.png
270 KB
Hallo liebes Forum, erstmal Danke für eure Teilnahme an der Diskussion, echt genial! Mir ist zwischenzeitlich beim Board abgeraucht, deswegen habe ich mich nicht mehr gemeldet. Zuviel dran rumgelötet... Achim S. schrieb: > PS: wenn du ein Re-Routing in Betracht ziehst, kommst du doch eigentlich > ganz ohne Treiber aus, oder? Wenn ich es richtig in Erinnerung habe, > geht es um eine Punkt zu Punkt Verbindung über 3 cm, das schaffen alles > FPGAs, mit denen ich bisher gearbeitet habe ;-) Leider nicht korrekt. Vom Buffer zum Sensor sind es 3cm. Der FPGA ist allerdings vom Buffer 20cm entfernt und über ein Flachbandkabel verbunden. Mein Konfiguration: Altera FPGA => 3cm Leitung => Stecker => 20cm Flachbandkabel => 2cm Leitung => Buffer mit Serienterminierung 33R => 3cm zum Sensor HildeK schrieb: > Wie viele Masseleitungen hast du denn auf dem Flachbandkabel spendiert? > Liegen da auch welche direkt neben der Taktleitung? Jede 2. Ader ist mit GND belegt. - Ich habe jetzt noch einmal mit einem RG174 einen Tastkopf aufgebaut und neue Messungen gemacht. Damit konnte ich jetzt auch GND direkt an die Platine anschliessen. - VCCA+VCCB haben jetzt jeweils 100nF und 10nF parallel spendiert bekommen - Den Serienwiderstand habe ich auf 33R erhöht, sowohl am Ausgang als auch am Eingang. => Es sieht garnicht so schlecht aus, der Sensor läuft jetzt... ALLERDINGS: a) sind Störungen auf dem Kamerabild, leider konnte ich bisher die Fehlerquelle noch nicht identifizieren, ich vermute aber das mir die 150MHz hier irgendwo durchschlagen :/ b) Ich habe noch ein 2. Board welches identisch zum ersten ist, bei welchem ich jetzt die 150MHz auch mit 33R in Serie terminiert habe und hier springt der Sensor nicht an, scheint also beim 1. Board irgentwie Zufall su sein :/ Im Anhang mal die Messungen... 1) FPGA_out.png => Kein Kabel angeschlossen, ca. 3cm vom FPGA entfernt 2) Nach_Kabel_vor_33R.png => Kabel angeschlossen und vor den 33R am Buffer Eingang gemessen 3) Buffer_Input_nach_33R.png => Kabel angeschlossen und nach den 33R am Buffer Eingang gemessen 4) Buffer_Output_vor_33R.png => Buffer Ausgang direkt (vor den 33R) 5) Buffer_Output_nach_33R.png => Buffer Ausgang nach den 33R 6) Direkt_am_Sensor_Pin.png => Direkt am Empfänger/Sensor-Pin gemessen Falls Ihr noch Ideen habt, immer her damit :) Mein Chef hat mir jetzt einen "P6158 20X Low Capacitance Probe" genehmigt, ist leider nirgends auf Lager, hoffe das dauert nicht zu lange ;) Ich denke ich komme um ein Redesign mit anderem Kabel (Highspeed Kabel mit terminiertem R=50 Ohm) und anderem Buffer wohl nicht herum. Dazu hätte ich noch die ein oder andere Frage, werde dafür aber besser einen neuen Thread aufmachen oder?
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.