Forum: FPGA, VHDL & Co. Taktrückgewinnung aus BMC-Daten-Signal


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Erik (Gast)


Lesenswert?

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

von Joe F. (easylife)


Lesenswert?

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
von Joe F. (easylife)


Lesenswert?

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.

von Antti L. (xilant)


Lesenswert?

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!

von Erik (Gast)


Lesenswert?

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

von Joe F. (easylife)


Lesenswert?

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... ?!

von Lars R. (lrs)


Lesenswert?

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.

von Ich (Gast)


Lesenswert?

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.

von Ingenieur (Gast)


Lesenswert?

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?

von Lars R. (lrs)


Lesenswert?

Ingenieur schrieb:
> Anntis Lösung
> Wie soll das gehen?

D=not(D)  ?

von Erik (Gast)


Lesenswert?

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

von Lars R. (lrs)


Lesenswert?

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
von Ingenieur (Gast)


Lesenswert?

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.

von Joe F. (easylife)


Lesenswert?

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
von Lars R. (lrs)


Lesenswert?

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
von Lattice User (Gast)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Erik (Gast)


Lesenswert?

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.

von Lars R. (lrs)


Lesenswert?

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.

von Joe F. (easylife)


Lesenswert?

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.

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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"...

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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?

von Erik (Gast)


Lesenswert?

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

von Lothar M. (Firma: Titel) (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Erik (Gast)


Lesenswert?

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

von Edi M. (Gast)


Lesenswert?

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?

von ElKo (Gast)


Lesenswert?

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.

von Weltbester FPGA-Pongo (Gast)


Lesenswert?

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.

von Edi M. (Gast)


Lesenswert?

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?

von HF-Techniker (Gast)


Lesenswert?

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.

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.