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:
| | | +-- 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.
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
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.
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
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.
