Hallo, ich habe einen kleinen FPGA (IGLOO von Microsemi) der mit einer simplen bidirektionalen seriellen Schnittstellen von einem entfernten großen FPGA (wahrscheinlich von Xilinx) gesteuert werden soll. Die serielle Verbindung besteht aus genau 2 Leitungen (eine pro Richtung) mit nicht bekannter Laufzeit so das der Takt jeweils im Datensignal mit enthalten sein muss. Dafür möchte ich http://de.wikipedia.org/wiki/Biphase-Mark-Code einsetzen, die Datenrate soll 50MBit/s betragen. Der kleine FPGA soll sich auf das ankommende Datensignal synchronisieren und mit diesem Takt intern arbeiten, es gibt dort keine lokale Taktquelle. Dieser Takt wird vom großen FPGA zusätzlich mit Spread-Spectrum-Clocking ein wenig verschliffen. Es ist sehr wichtig das der interne Arbeitstakt im kleinen FPGA auch das Spread-Spectrum-Clocking, das vom großen FPGA vorgegeben wird, exakt mitmacht. Mein Problem ist nun wie ich im kleinen FPGA den Takt zuverlässig aus dem empfangenen Datensignal extrahiere und damit dessen PLL füttere. Das BMC-Signal hat zwar am Anfang jeder Bitperiode einen Pegelwechsel aber trotzdem kann ich dieses Signal nicht einfach in eine PLL einspeisen. Meine derzeitige Idee sieht vor das ich mit einer kleinen Verzögerungslinie (ca. 3ns) im FPGA und einem XOR (aus Eingang und Ausgang der Verzögerungslinie) ein Pulssignal erzeuge. Dieses Pulssignal kommt in den Eingang der PLL. Solange das BMC-Signal nur aus 0-Bits besteht, also eine simple 25MHz-Frequenz darstellt, bekommt somit die PLL ein 50MHz-Signal mit recht kleinem Duty-Cycle zu sehen und sollte in der Lage sein sich darauf zu synchronisieren. Sobald die PLL gelockt hat und intern ein phasensynchroner 50MHz-Arbeitstakt (mit 50% Duty-Cycle) ansteht sendet der kleine FPGA auf der Rückleitung auch ein BMC-Signal was der große FPGA als Bestätigung erkennt das der kleine FPGA sich erfolgreich synchronisiert hat. Sobald im dem BMC-Signal auch 1-Bits enthalten sind kommt aus dem XOR ein Plussignal mit einer Frequenz zwischen 50MHz und 100MHz so das ich alle Pulse die aus dem Pegelwechsel in der Mitte der Bitperiode entstehen gezielt ausfiltern muss. Dazu möchte ich den 50MHz-Ausgangstakt der PLL verwenden, es sollte möglich sein diesen um etwa 120° gegen den Takt des Pulssignal zu verschieben (trotz Spread-Spectrum-Clocking sollte die interne Verzögerung der PLL dazu präzise genug sein). Die steigende Flanke von dem Pulssignal sollte relativ wenig jittern und wenn die steigende Flanke des internen 50MHz-Arbeitstakts etwa 7ns später kommt sollten die Pulse aus der Mitte der Bitperiode immer komplett in der High-Phase des internen Arbeitstakts liegen so dass das XOR am Anfang nur noch zusätzlich ein Enable benötigt das den XOR-Ausgang mit dem Low-Pegel des Arbeitstakts freigibt. Seht Ihr in meiner Idee irgendwelche Probleme? Gibt es eine bessere Möglichkeit mein Problem zu lösen? Grüße Erik
Muss das Signal denn "symmetrisch" sein? Das benötigt man ja hauptsächlich für Übertragung per Funk (bzw. AC Koppelung). Ich finde den Ansatz des 1-wire Protokolls ja ganz charmant. https://de.wikipedia.org/wiki/1-Wire Aus einer Clockflanke (bei 1-wire fallend) kann man den Takt extrahieren. Mit definierter Verzögerung zu dieser Flanke wird das Datenbit gesampled. Das Timing, und die Flankenpolarität kann man ja abwandeln, so dass man mit einer 200 MHz Clock 50 Mbit +/-25% verarbeiten können sollte:
1 | | 0 | 1 | 1 | 0 | <- 50 Mbit Signal |
2 | _ _____ _____ _ |
3 | _/ \_____/ \_/ \_/ \_____ |
4 | ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ <- 200 MHz Abtastung |
5 | | | | | usw. |
6 | | | | +-- 4) 2 Takte später nächstes Bit samplen (high) |
7 | | | +------ 3) nächste steigende Flanke erkannt |
8 | | +---------- 2) 2 Takte später Bit samplen (low) |
9 | +-------------- 1) steigende Flanke erkannt |
Nach dem sampeln des Datenbits wird natürlich nicht starr 2 Takte gewartet, sondern darauf, dass tatsächlich wieder ein Takt-Flankenwechsel (in meinem Beispiel low->high) stattfindet. Das kann bereits beim nächsten Takt sein, oder erst 3 Takte später. Dadurch synchronisiert sich das ganze dann.
:
Bearbeitet durch User
Sorry, für 25% Toleranz benötigst du eine 400 MHz Abtastung. Also nach der low-high Flankenerkennung genau 4 Takte danach das Datenbit sampeln, dann auf low warten, und mit der Erkennung der nächsten low-high Flanke weitermachen.
es geht SO: in Master hast 100mhz clock, davon erzeugst für 0 1000 für 1 1110 mit hilfe DDR ausgang flop. in SLAVE, hast input zu FLIP FLOP, ausgang von dem flip flop ist immer 25mhz duty cycle 50:50 :) das geht in PLL in der slave, PLL ausgang takt verwendust für ein flop flop das von eingangs signal daten herzaubert im Slave verwendest den PLL clock zum senden, der Slave braucht überhaupt keine takt quelle. Habe so was implementiert, geht so! Fertik!
Hallo, was ihr mir vorschlagt ist eine Art Duty-Cycle-Modulation. Diese Idee hab ich auch schon verfolgt da die Takt-Rückgewinnung hier sehr einfach ist (das Signal kann ohne jede Aufbereitung direkt in den PLL-Eingang) und wenn der Ausgangstakt der PLL anständig phasensynchron ist (50% Duty-Cycle sollte er eh haben) kann man einfach mit dessen fallender Flanke den Wert des aktuellen Bits ermitteln (bei Duty-Cycle deutlich unter 50% würde eine 0 gesampled werden und bei einem Duty-Cycle deutlich über 50% eine 1). Das Problem ist dass das Signal so leider nicht DC-frei ist, deswegen hatte ich schon an eine 8B/10B-Codierung oder Scrambling oder andere Sachen nachgedacht aber all diese Dinge dürften einen IGLOO-FPGA schon vom Umfang her deutlich überfordern. Es ist mir ziemlich wichtig dass das ganze möglich simple ist und möglichst wenig Logik erfordert. Dass das Signal DC-frei sein muss hab ich leider vergessen zu erwähnen, Sorry dafür, aber es geht über eine längere Verbindung zwischen verschiedenen Platinen und da sind alle Signale differentiell und eben auch DC-frei. Gibt es zu meiner Idee mit dem BMC-Code noch Anmerkungen, Kritik oder Vorschläge? Grüße Erik
Erik schrieb: > Dass das Signal DC-frei sein muss hab ich leider vergessen zu erwähnen, > Sorry dafür, aber es geht über eine längere Verbindung zwischen > verschiedenen Platinen und da sind alle Signale differentiell und eben > auch DC-frei Auch wenn die Signale längere Verbindungsstrecken haben, differentiell sind und über verschiedene Platinen gehen, erschließt es sich mir nicht, warum es nötig sein sollte es DC-frei zu implementieren... ?!
Erik schrieb: > Gibt es zu meiner Idee mit dem BMC-Code noch Anmerkungen, Kritik oder > Vorschläge? Was Du schreibst, habe ich ungefähr nachvollzogen für eine Folge von Nullen mit einer anschließenden Folge von Einsen. Ist bei Deinem Ansatz auch berücksichtigt, dass jede 1 in einer Folge von vielen Nullen Deinen "Eingangstakt" um 180Grad verschiebt? ...Die DC-Sorgen bei LVDS würden mich auch interessieren.
Bin nur über "Igloo" und "PLL" gestolpert - Hinweis am Rande: Datenblatt genau lesen! Bei den Igloo nano ging die PLL nicht in allen Packages zu nutzen, was nur in einer kleinen Fußnote stand.
Lars R. schrieb: > ...Die DC-Sorgen bei LVDS würden mich auch interessieren. MBC is per Definition gleichstromfrei, meine ich. Was mich aber irritiert: Anntis Lösung impliziert eine Einflussnahme auf die Implementierung des Masters, die mir nicht gegeben scheint. Zudem misslingt die Taktrekonstruktion mit PLL dann, wenn nicht ein exakter 01-Wechsel kommt. Wie soll das gehen?
Hallo, Danke für Eure Antworten. Joe F. schrieb: > erschließt es sich mir nicht, warum es nötig sein sollte > es DC-frei zu implementieren... ?! Die Platinen haben unterschiedliches Masse-Potential, der Kollege der die Elektronik macht hat sich zwar noch nicht festgelegt aber ein Trenntrafo für jedes einzelne Signal ist im Gespräch (auch deswegen bekomme ich für die bidirektionale FPGA-to-FPGA-Kommunikation nur 2 Signale). Lars R. schrieb: > Ist bei Deinem Ansatz auch berücksichtigt, dass jede 1 in einer > Folge von vielen Nullen Deinen "Eingangstakt" um 180Grad verschiebt? Ja, das ist ja das tolle an der BMC-Codierung, die ist nicht nur DC-frei sondern auch unabhängig von der Polarität, es kommt nur auf den zeitlichen Ablauf der Flanken an und nicht darauf in welche Richtung die Flanken gehen. Das XOR mit der Verzögerungslinie macht eine Art Frequenzverdopplung weil aus jeder ankommenden Signal-Flanke ein Puls (mit zwei Flanken) wird, egal was für eine Flanke ankommt das XOR macht daraus immer eine steigende Flanke und mit kurzer Verzögerung eine fallende Flanke dazu. Die steigende Flanke von dem so gewonnenen Pulssignal wird dann von der PLL verarbeitet, im FPGA-Datenblatt gibt es für den Duty-Cycle des Eingangstakts keine Beschränkungen (nur der Jitter der steigenden Flanke des Eingangstakts ist reglementiert) und zur Not mache ich mit einem simplen Flip-Flop daraus ein Signal mit halber Frequenz aber 50%-Duty-Cycle. Aufgrund dessen das, nachdem sich die PLL auf ein BMC-Eingangssignal aus lauter Nullen synchronisiert hat, jede Flanke in der Mitte der Bitperiode ausgefiltert wird bekommt die PLL auch weiterhin nur die Flanke (bzw. den daraus generierten Puls) am Anfang der Bitperiode zu sehen, es bleibt also bei dem 50MHz-Pulssignal egal was für Kombinationen aus 0-Bits und 1-Bits kommen. Einzigste Voraussetzung ist das der Sender solange nur Nullen sendet (quasi als Link-Training-Pattern) bis er weiß das der Empfänger in meinem FPGA sich erfolgreich synchronisiert hat und das sollte einfach machbar sein da mein FPGA erst dann anfängt selber mit einem BMC-Signal zu antworten wenn die PLL erfolgreich eingerastet ist. Auf die Implementierung im Master habe ich durchaus Einfluss, ich soll den VHDL-Code für beide Seiten der Verbindung und den kompletten IO-Expander-FPGA (den kleinen IGLOO) liefern. Im Master steht mir wahrscheinlich ein 200MHz-Takt zur Verfügung, aber dieser Takt ist per Spread-Spectrum-Clocking etwas verschliffen (wegen EMV und solchen Dingen). Da der Master mehrere solcher Interfaces bieten muss und ich somit nicht für jedes empfangene Signal eine PLL verbrauchen kann werde ich dort mit Oversampling arbeiten (200MHz sollten für 50Mit/s ausreichen selbst dann wenn Frequenz und Phasenlage leicht schwanken, das Rücksignal wird zwar dem Spread-Spectrum-Clocking perfekt folgen aber eben immer mit einer kleinen zeitlichen Verzögerung). Gast schrieb: > Bei den Igloo nano ging die PLL nicht in allen Packages zu > nutzen, was nur in einer kleinen Fußnote stand. Die Designsoftware weiß das aber auch und würde sich weigern ein Bitstream zu generieren wenn der gewünschte FPGA im gewünschten Package die erforderlichen Möglichkeiten nicht bietet. Grüße Erik
Erik schrieb: > [...] Danke für die Ausführung. Natürlich. Gedanklich hatte ich das Verzögerungsglied an einer anderen Stelle. > Im Master steht mir > wahrscheinlich ein 200MHz-Takt zur Verfügung, aber dieser Takt ist per > Spread-Spectrum-Clocking etwas verschliffen (wegen EMV und solchen > Dingen). Da der Master mehrere solcher Interfaces bieten muss und ich > somit nicht für jedes empfangene Signal eine PLL verbrauchen kann werde > ich dort mit Oversampling arbeiten (200MHz sollten für 50Mit/s > ausreichen selbst dann wenn Frequenz und Phasenlage leicht schwanken, > das Rücksignal wird zwar dem Spread-Spectrum-Clocking perfekt folgen > aber eben immer mit einer kleinen zeitlichen Verzögerung). Bei Xilinx gibt es zur Laufzeit einstellbare Verzögerungsglieder. Ein Stück pro IO und bei LVDS stehen 2 zur Verfügung. Benutzt wird dann 1x synchronisiert und 1x zum kontinuierlichen Neuausmessen des Fensters im laufenden Betrieb. Hier mit Deser: http://www.xilinx.com/support/documentation/application_notes/xapp860.pdf Edit: "IODELAY" "IDELAY" Grüße, Lars
:
Bearbeitet durch User
Lars R. schrieb: > Ingenieur schrieb: >> Anntis Lösung >> Wie soll das gehen? > > D=not(D) ? Es ging darum wie man aus einem ungleichmässigen Datenstrom eine PLL füttern soll.
Erik schrieb: > Joe F. schrieb: >> erschließt es sich mir nicht, warum es nötig sein sollte >> es DC-frei zu implementieren... ?! > Die Platinen haben unterschiedliches Masse-Potential, der Kollege der > die Elektronik macht hat sich zwar noch nicht festgelegt aber ein > Trenntrafo für jedes einzelne Signal ist im Gespräch (auch deswegen > bekomme ich für die bidirektionale FPGA-to-FPGA-Kommunikation nur 2 > Signale). Optokoppler wären auch eine Möglichkeit. Günstiger, kleiner, und DC geeignet.
:
Bearbeitet durch User
Ingenieur schrieb: >>> Anntis Lösung >>> Wie soll das gehen? >> D=not(D) ? > Es ging darum wie man aus einem ungleichmässigen Datenstrom eine PLL > füttern soll. Taktflankengesteuertes FF mit . Dateneingang D . Ausgang Q und . Clockeingang C PLL_INPUT=Q D=not(Q) C= Daten vom Master 1000 1000 1110 1000 1110 1110 0 0 1 0 1 1 FF schaltet auf Taktflanke: 0->1
:
Bearbeitet durch User
Wenn die PLL einen externen Loopback erlaubt, kannst du vielleicht folgendes implementieren: https://en.wikibooks.org/wiki/Clock_and_Data_Recovery/Structures_and_types_of_CDRs/The_CDR_phase_comparator#The_.22linear.22_phase_comparator Das XOR ist der Phasencomparator in der PLL. Mit einem DC freien Code sollte das Risiko dass die PLL wegdrifted klein genug sein. Ausprobieren, Jitter messen, Biterrorrate messen.
Erik schrieb: > das Rücksignal wird zwar dem Spread-Spectrum-Clocking perfekt folgen Du hast aber ein gutes Vertrauen in die Regelschleife der PLL... :-o Hast du das ausprobiert oder wünschst du dir das nur? > 200MHz sollten für 50Mit/s ausreichen selbst dann wenn Frequenz und > Phasenlage leicht schwanken Das glaube ich erst, wenn ich es gesehen habe. Du hast bei dieser geringen Überabtastung m.E. nicht ausreichend Platz für ein Resync, denn die PLL wird (wie festgestellt) einer Taktänderung bestenfalls verzögert folgen. > ein Trenntrafo für jedes einzelne Signal ist im Gespräch Kommt da noch irgendwelche Physik zur Ankopplung dieses analogen Bauteils dazu? Joe F. schrieb: > Optokoppler wären auch eine Möglichkeit. Für 50MHz Datenrate aber auch ganz hübsch sportlich...
Hallo, Ingenieur schrieb: > Es ging darum wie man aus einem ungleichmässigen Datenstrom eine PLL > füttern soll. Der Datenstrom ist nicht ungleichmäßig. Weder bei BMC noch bei der Duty-Cycle-Modulation (1-Wire-Prinzip). Bei beiden Varianten kommt am Anfang jeder Bitperiode eine Flanke, bei der Duty-Cycle-Modulation ist es sogar immer eine steigende Flanke so das man sich die Verzögerungslinie mit XOR zwecks Pulsformung sparen kann. Beim BMC kommt entweder in der Mitte der Bitperiode eine weitere Flanke (1-Bit) oder nicht (0-Bit) und bei der Duty-Cycle-Modulation kommt immer eine weitere Flanke (die fallende) innerhalb der Bitperiode nur das hier die zeitliche Position schwankt (vor der Mitte für 0-Bit und nach der Mitte für 1-Bit). Die Schwierigkeit bei der BMC-Decodierung besteht darin die Flanke in der Mitte der Bitperiode zuverlässig auszufiltern bevor das Pulssignal in die PLL kann. Solange das Signal nur aus 0-Bits besteht kann man jede empfangene Flanke (als Puls umgeformt) zur PLL durchlassen und nachdem sich die PLL erfolgreich gelockt hat kann man deren Ausgangstakt (der eine geeignete Phasenlage zum Eingangssignal haben muss was aber für eine anständige PLL kein Problem ist) als Filter benutzen um die Flanken in der Mitte der Bitperiode gezielt auszufiltern. Data-Bits: 0 0 1 0 1 1 Signal: |0 0 0 0|1 1 1 1|0 0 1 1|0 0 0 0|1 1 0 0|1 1 0 0| Pulse: 1 0 0 0 1 0 0 0 1 0 1 0 1 0 0 0 1 0 1 0 1 0 1 0 Ausgangstakt aus der PLL, 90° phasenverschoben: 001111000011110000111100001111000011110000111100 gefiltertes Pulssignal (Eingang für die PLL): 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 Lars R. schrieb: > Bei Xilinx gibt es zur Laufzeit einstellbare Verzögerungsglieder. Okay, aber was soll mir das bringen? Mit dem 200MHz-Takt und DDR-Input-Registern kann ich pro 20ns Bitperiode 8 mal samplen, meiner Meinung nach sollte das reichen um zur Flanke vom Anfang jeder Bitperiode zuverlässig synchron zu bleiben. Da die Laufzeit der Leitungen nicht bekannt ist gibt es zwischen gesendetem Daten-Signal und empfangenen Daten-Signal am Master eh keinen zeitlichen Bezug. Lothar M. schrieb: >> das Rücksignal wird zwar dem Spread-Spectrum-Clocking perfekt folgen > Du hast aber ein gutes Vertrauen in die Regelschleife der PLL... :-o > Hast du das ausprobiert oder wünschst du dir das nur? Das ist es was ich von einer PLL erwarte. Falls die PLL das nicht erfüllt müssten im Takt irgendwo Sprünge drin sein und sowas hab ich bis jetzt noch nie am Oszi gesehen. >> ein Trenntrafo für jedes einzelne Signal ist im Gespräch > Kommt da noch irgendwelche Physik zur Ankopplung dieses analogen > Bauteils dazu? Es ist geplant beide Leitungen des differentiellen Signals am FPGA mit je 100 Ohm an Vio/2 zu terminieren. Das ein digitales Signal hinter einem Trafo nicht mehr ganz so digital aussieht ist mir bewusst aber aus meiner Sicht kommt es primär auf den Nulldurchgang der Spannungsdifferenz an und der sollte doch einigermaßen ordentlich bleiben (sowohl was Steilheit als auch was zeitliche Position angeht). >> Optokoppler wären auch eine Möglichkeit. > Für 50MHz Datenrate aber auch ganz hübsch sportlich... Und nicht unbedingt preiswert. Nebst dessen das wegen der bidirektionalen Arbeitsweise auch auf der "Außenseite" des Optokopplers eine geeignete also potentialfreie Versorgungsspannung vorhanden sein muss und die kostet weitere Platinenfläche und Geld.
Erik schrieb: >> Bei Xilinx gibt es zur Laufzeit einstellbare Verzögerungsglieder. > Okay, aber was soll mir das bringen? Es war als eventuelle, optionale Alternative zum Oversampling gedacht. > Mit dem 200MHz-Takt und > DDR-Input-Registern kann ich pro 20ns Bitperiode 8 mal samplen, meiner > Meinung nach sollte das reichen um zur Flanke vom Anfang jeder > Bitperiode zuverlässig synchron zu bleiben. Wenn das funktioniert, brauchst Du die Verzögerungsglieder natürlich nicht.
Erik schrieb: >>> Optokoppler wären auch eine Möglichkeit. >> Für 50MHz Datenrate aber auch ganz hübsch sportlich... > Und nicht unbedingt preiswert. Toshiba TLP117(F) 1 EUR irgendwas bei Mouser > Nebst dessen das wegen der > bidirektionalen Arbeitsweise auch auf der "Außenseite" des Optokopplers > eine geeignete also potentialfreie Versorgungsspannung vorhanden sein > muss und die kostet weitere Platinenfläche und Geld. Natürlich sind auf beiden Seiten bereits unabhängige, und potentialgetrennte Versorgungsspannungen vorhanden. Das ist doch gerade der Sinn und Grund der galvanischen Trennung der Datenleitungen, oder nicht? Wenn das nicht so ist, benötigt man weder Optokoppler noch Trafos.
Erik schrieb: >> Hast du das ausprobiert oder wünschst du dir das nur? > Das ist es was ich von einer PLL erwarte. Wenn es wirklich eine PLL im analogen Sinne ist. Ein digitaler Clockmanager kann da schon mal den Tritt verlieren und aussetzen. Wenn ein "loss of lock" passiert ist, zeigt er es dann mit einem (kurzzeitig) inaktivem "Lock"-Signal an... > Das ein digitales Signal hinter einem Trafo nicht mehr ganz so digital > aussieht ist mir bewusst aber aus meiner Sicht kommt es primär auf den > Nulldurchgang der Spannungsdifferenz an und der sollte doch einigermaßen > ordentlich bleiben (sowohl was Steilheit als auch was zeitliche Position > angeht). Ja, das will ich mal so sagen: um zu beweisen, dass ein Ethernet auch ohne PHY geht, da ist das Gebastel mit dem Trafo direkt am FPGA noch denkbar. Das kann man über irgendwelche Schaltschwellen hinweg dann so hintricksen, dass es geht. Aber für eine kommerzielle Lösung ist dieses Vorgehen verwegen. > und der sollte doch einigermaßen ordentlich bleiben Wie wäre es, einfach mal ein solches Signal zu erzeugen und über den Trafo auf das Iglu zu geben und dort ohne weitere Verarbeitung wieder auszugeben. Und dann in dieser Kette mal zu messen und an Parametern wie Leitungslänge usw. zu drehen. Dann würde aus dem "sollte" ein "ist"...
Joe F. schrieb: > Toshiba TLP117(F) Die Tphl und Tplh sind hier jeweils maximal 30ns. Eine Abhängigkeit der beiden zueinander ist nicht spezifiziert. Was, wenn die Tplh 0 und die Tphl 30ns ist?
Hallo, Lars R. schrieb: > Es war als eventuelle, optionale Alternative zum Oversampling gedacht. Achso, Du meinst ich soll damit das Daten-Signal so hinschieben das immer ein konstanter Phasenbezug zum lokalem Takt besteht. Sowas hab ich bis jetzt noch nicht gemacht und ich stelle mir das relativ aufwendig vor, aber ich werde mir die Doku von Xilinx mal näher ansehen. Das Oversampling ist IMHO relativ simpel und ich hab mit sowas Erfahrung. Joe F. schrieb: > Toshiba TLP117(F) Schau mal ins Datenblatt auf Seite 4, dort steht für "Switching time dispersion" bis zu 8ns und das ist deutlich zu viel, auf einen so großen Jitter in den Flanken kann sich keine PLL mehr synchronisieren. Nebst dessen das sich die 50Mb/s auf NRZ beziehen, also maximal alle 20ns eine Flanke. Bei BMC kommen die Flanken aber entweder in 20ns Abstand oder in 10ns Abstand und bei der Duty-Cycle-Modulation beträgt der Abstand 5ns und 15ns. Für solche Anforderungen kostet ein Optokoppler deutlich mehr als 1 Euro. Außerdem kann der TLP117 kein LVDS was zusätzliche Treiber/Receiver erfordert und ist obendrein ein 5V-Bauteil was mit FPGAs der letzten 10 Jahre nicht mehr kompatibel ist. Das Signal hier wird mit 1,5V-LVDS betrieben, da ist eine AC-Kopplung mit Kondensatoren oder mit Trafo die einfachste und billigste und auch platzsparendste Variante, wobei der Trafo den Vorteil der fehlenden kapazitiven Kopplung für sich verbuchen kann. Joe F. schrieb: > Natürlich sind auf beiden Seiten bereits unabhängige, und > potentialgetrennte Versorgungsspannungen vorhanden. Natürlich, aber auf zwei verschiedenen Platinen und keine Platine schickt ihre lokale Versorgungsspannung über eine lange Leitung zur anderen Platine (wenn ich sowas vorschlagen würde würden mir die Elektronik-Leute wahrscheinlich sofort tödliche Blicke zuwerfen). Es handelt sich hier um Elektronik für den Einsatz in der Industrie und da ist Immunität gegen EMV-Zeugs oberstes Gebot. Im Gespräch sind derzeit Trafos auf beiden Seiten für alle Signale, es kommt hier nicht so sehr darauf an die Platinen gegeneinander abzusichern sondern jede Platine gegen die Leitung abzusichern. Lothar M. schrieb: > Wenn es wirklich eine PLL im analogen Sinne ist. Ein digitaler > Clockmanager kann da schon mal den Tritt verlieren und aussetzen. Wenn > ein "loss of lock" passiert ist, zeigt er es dann mit einem (kurzzeitig) > inaktivem "Lock"-Signal an... In jedem FPGA-Design das ich die letzten 10 Jahre gemacht habe habe ich das Lock-Signal der PLL immer mit ins interne Reset-Signal einfließen lassen und ich hab nie erlebt das die Logik im FPGA unerwartet resetet wurde (auch nicht unter sehr rauen EMV-Bedingungen). Ich gehe also tatsächlich davon aus das eine PLL mit internem VCO der von einem Phasen-Komparator gesteuert wird am Ausgang genau so viele Takte abliefert wie am Eingang reingekommen sind (bei Taktverhältnis 1:1 natürlich). Lothar M. schrieb: > einfach mal ein solches Signal zu erzeugen und über den Trafo .... Ich hab schon ein paar mal mit nem Trenntrafo gearbeitet, u.a. als Potentialtrennung an einem FET-Gate, und hinter dem Trafo sahen die Signale noch ziemlich gut aus. Ich hab auch schon mal an einer aktiven 100MBit-Ethernet-Leitung das Oszi vor und hinter dem Trafo angeschlossen und die beiden Signale verglichen, vom Rundschleifen der steilen/digitalen Flanken mal abgesehen war die Ähnlichkeit noch ziemlich groß. Grüße Erik
Erik schrieb: > ich hab nie erlebt das die Logik im FPGA unerwartet resetet wurde Auch nicht mit jitterndem Takt? Ich schon. > Ich hab auch schon mal an einer aktiven 100MBit-Ethernet-Leitung das > Oszi vor und hinter dem Trafo angeschlossen und die beiden Signale > verglichen, vom Rundschleifen der steilen/digitalen Flanken mal > abgesehen war die Ähnlichkeit noch ziemlich groß. Ich sage ja nicht, dass es nicht geht. Zum Basteln würde ich mich schon mal trauen, mit einem Trafo an einen digitalen Eingang zu gehen. Aber kommerziell und in Serie? Da würde ich mich fragen: warum machen die dann beim Ethernet so eine Hektik mit ihrem PHY, der zudem oft noch in anderer Technik gefertigt wird, eben weil er intern recht analog ist... > Ich hab auch schon mal an einer aktiven 100MBit-Ethernet-Leitung das > Oszi vor und hinter dem Trafo angeschlossen und die beiden Signale > verglichen Wie gesagt: mach das nicht mit der Hardware des PHYs, der da mit Equalizing und sonstnochwas die Signale schon beim Absenden schon hinbiegt, sondern mach es mit dem LVDS-Ausgang des Xilinx und mit dem Eingang des IGLOOs und route die Signale einfach mal so durch die FPGAs durch. Und wenn dort die Signale vom Signalgenerator bis zum Abschlusswiderstand gut aussehen, dann taugt diese Übertragungskette, denn das wäre für mich eine belastbare Messung.
Hallo, Lothar M. schrieb: >> ich hab nie erlebt das die Logik im FPGA unerwartet resetet wurde > Auch nicht mit jitterndem Takt? Ich schon. Ich tatsächlich noch nicht, offensichtlich hatte ich es noch nie mit so stark jitterndem Takt zu tun. Ich hab auch schon mal von einem Source-Synchronous-Interface den mitgelieferten Takt (aber auf einer extra Leitung) in eine PLL eingespeist (wimre in einen Spartan 3) und auch da hatte ich keine Probleme damit. Mir ist aber bewusst das gerade die Verarbeitung des Eingangssignals vor der PLL in asynchroner Logik hier ein gewisses Problempotential bietet, das ist ja einer der Gründe warum ich zu meiner eigentlichen Idee gerne Kommentare und Anregungen möchte. Lothar M. schrieb: > Zum Basteln würde ich mich schon mal trauen, mit einem Trafo an einen > digitalen Eingang zu gehen. Aber kommerziell und in Serie? > Da würde ich mich fragen: warum machen die dann beim Ethernet so eine > Hektik mit ihrem PHY .... Ethernet ist schon was anderes, selbst 100MBit-Ethernet ist mit seiner MLT-3-Codierung bereits kein digitales Signal mehr (1GBit-Ethernet mit PAM-5 erst recht nicht mehr), zu Zeiten des 10MBit-Ethernet mit seiner Manchester-Codierung (im Prinzip fast das selbe wie die BMC-Codierung) waren externe PHYs noch nicht üblich. Aber Du hast natürlich recht das ein simpler LVDS-Eingang eines normalen FPGA vermutlich etwas überfordert ist mit einem Signal das deutliche Tendenzen in Richtung Analog aufweist. Ein weiterer Aspekt bereitet mir da Sorgen: die LVDS-Input-Komparatoren haben üblicherweise keine richtige Hysterese so das ein inaktives Signal dessen Differentialspannung recht exakt auf 0.0V liegt Probleme verursachen dürfte. Meines Wissens nach könnte so ein Eingang ins Schwingen geraten weil das natürliche Spannungsrauschen den Eingang zufällige Pegelwechsel erkennen lässt. Im Hinblick auf ein klar definiertes Verhalten ist hier wahrscheinlich ein externer Komparator mit definierter Hysterese eine gute Variante. Nebst dessen das so auch die empfindlichen FPGA-IO-Pins nicht mehr direkt mit der EMV-belasteten Außenwelt verbunden sind. Lothar M. schrieb: > .... dann taugt diese Übertragungskette, > denn das wäre für mich eine belastbare Messung. Keine Sorge, bevor das in Serie geht wird das auf jeden Fall gründlich durchgemessen. Sollte es tatsächlich externe Beschaltung (Komparator als Empfänger) geben möchte ich frühestmöglich so eine Verbindung mal ohne FPGAs aber mit Kabel, Steckern und Trafos aufbauen um zu sehen wie die Leitung ansich aussieht. Grüße Erik
Erik schrieb: > Ein weiterer Aspekt bereitet mir da Sorgen: die LVDS-Input-Komparatoren > haben üblicherweise keine richtige Hysterese so das ein inaktives Signal > dessen Differentialspannung recht exakt auf 0.0V liegt Probleme > verursachen dürfte. Ist doch ein undefinierter Zustand, oder?
E. M. schrieb: > Erik schrieb: >> Ein weiterer Aspekt bereitet mir da Sorgen: die LVDS-Input-Komparatoren >> haben üblicherweise keine richtige Hysterese so das ein inaktives Signal >> dessen Differentialspannung recht exakt auf 0.0V liegt Probleme >> verursachen dürfte. > > Ist doch ein undefinierter Zustand, oder? Ja, der Zustand ist undefiniert. Deswegen hat Analog Devices zum Beispiel zwei verschiedene Typen an LVDS-Transceivern im Angebot. Mit LVDS Typ 1 (delta V = 0 ist undefiniert) und LVDS Typ 2 (delta V = 0 ist Logic 0). Hysterese ist bei LVDS unüblich, in der Regel wird ein Bereich der Differenzspannung definiert, in dem kein logisches Ausgangssignal garantiert wird. Das Datenblatt von den Analog Devices Transceivern ist sehr lesenswert: http://www.analog.com/media/en/technical-documentation/data-sheets/ADN4691E_4693E_4696E_4697E.pdf Übrigens haben wir ähnliche Experimente hinter uns. Wir haben das LVDS kapazitiv entkoppelt. Als Protokoll kam UART zum Einsatz mit einigen leichten Anpassungen, damit es dem UART-Frame gerecht wird, und trotzdem DC=0 garantiert wird. Da kamen dann Präambeln, Flags, Escape-Zeichen usw. ins Spiel. Wir haben natürlich gleich noch Multipoint ins Spiel gebracht, weils so schön war.
Ich verstehe aber noch nicht, warum das ein Problem ist. Liegt es an einem zu langen undefinierten Signal und toggelndem Eingang des LVDS-buffers? Sowas kann man doch leicht in SW im FPGA killen.
ElKo schrieb: > Übrigens haben wir ähnliche Experimente hinter uns. Wir haben das LVDS > kapazitiv entkoppelt. Als Protokoll kam UART zum Einsatz mit einigen > leichten Anpassungen, damit es dem UART-Frame gerecht wird, und trotzdem > DC=0 garantiert wird. Da kamen dann Präambeln, Flags, Escape-Zeichen > usw. ins Spiel. Wir haben natürlich gleich noch Multipoint ins Spiel > gebracht, weils so schön war. Darf man da mehr zu wissen?
Erik schrieb: > Solange das Signal nur aus 0-Bits besteht > kann man jede empfangene Flanke (als Puls umgeformt) zur PLL durchlassen Hat denn der Sender so ein Format? Was mir von BMC / Manchester bekannt ist, läuft der Hase so, daß das Signal extra deshalb konstant "ON" ist, ohne Daten zu senden, damit sich ein Empfänger überhaupt synchen kann. Nur dadurch ist die Gleichstromfreiheit gewährleistet. Lothar M. schrieb: > Joe F. schrieb: >> Optokoppler wären auch eine Möglichkeit. > Für 50MHz Datenrate aber auch ganz hübsch sportlich... Kommt auf die Type an. Bei dem TOSLINK-Zeug für Audio handelt es um Konsumerprodukte. Da darf man nicht viel erwarten. >> ein Trenntrafo für jedes einzelne Signal ist im Gespräch > Kommt da noch irgendwelche Physik zur Ankopplung dieses analogen > Bauteils dazu? In der Regel tut es ein kleiner Übertrager oder bei den Frequenzen auch eine rein kapazitive Koppelung.
HF-Techniker schrieb: > Lothar M. schrieb: >> Joe F. schrieb: >>> Optokoppler wären auch eine Möglichkeit. >> Für 50MHz Datenrate aber auch ganz hübsch sportlich... > Kommt auf die Type an. Bei dem TOSLINK-Zeug für Audio handelt es um > Konsumerprodukte. Da darf man nicht viel erwarten. Die Signale aus den Optokopplern sind ziemlich abgerundet, das stimmt - allerdings habe ich schon 50MHz benutzt - für 384kHz S/PDIF. Man muss gfs etwas oversannen, denn: ElKo schrieb: > Hysterese ist bei LVDS unüblich, Das würde auch die Umschaltgeschwindigkeit der Schaltung und damit deren maximale Frequenz beschränken. Es gibt da auch nicht wirklich den Bedarf für eine Hysterese, wenn man zusieht, dass das treibende Signal ausreichend steil ist, damit es nicht durch Rauschen mehrfach kippt. Bei der Taktrückgewinnung muss das natürlich berücksichtigt werden, was aber beim BMC sehr einfach ist.
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.