Forum: Mikrocontroller und Digitale Elektronik LWL Broadcom AFBR-26xx DC-50Mbd codierung


von FPGA (Gast)


Lesenswert?

Kurz eine frage: was ist der Versatile Link?

Gem. Broadcom kann der DC-50Mbaud. Die frage ist wie? Meine vermutung 
100MHz Manchester codierung? Oder ist dies Asynchron gedacht? Habe 
leider keine Infos zu dem Versatile Link gefunden. Hat jemand einen 
stabilen schnelleren datenaustausch über diese broadcom dinger 
hinbekommen? Evtl gerade mit entsprechendem HDL code?

von Gustl (Gast)


Lesenswert?

Also wenn das das ist was HP/Agilent damals gebaut haben, dann ist das 
nur eine Verbindung. Wie ein Draht. Was du darüber sprichst ist deine 
Sache. Du kannst da UART drüber machen wenn du was Einfaches suchst.

https://datasheet.octopart.com/HFBR-0501..-Avago-datasheet-638168.pdf

von FPGA (Gast)


Lesenswert?

Gustl schrieb:
> Wie ein Draht

Hmmm dann ist aber seltsam das sie DC-50 Mbd und nicht die bandbreite 
DC-xxMHz spezifizieren.
Nun UART mit 50mbaud? Mein erster gedanke war das clk wohl mitgesendet 
wird (NRZ zb.) anyway dies erhöht natürlich die benötigte Bandbreite.

Kann dies über den uC oder auch FPGA machen. Anyway uC wäre bevorzugt, 
also wenn 50 mdaud mittels eines usart vom STM32H7 gehen würden wäre 
dies perfekt.

von FPGA (Gast)


Lesenswert?

FPGA schrieb im Beitrag #6840196:
> 50 mdaud mittels eines usart vom STM32H7 gehen würden

Wird wohl nur im fpga gehen aufgrund limitierungen im H7 (12mbaud 
usart). Selbst im FPGA evtl anspruchsvoll da hoher clk benötigt.

von Gerd E. (robberknight)


Lesenswert?

FPGA schrieb im Beitrag #6840172:
> Gem. Broadcom kann der DC-50Mbaud. Die frage ist wie?

Ich verstehe das Datenblatt so daß das Dein Problem ist. Du hast einen 
Dateneingang am Transmitter und einen Datenausgang am Receiver. Die 
Codierung, Clocking etc. ist Dir überlassen.

FPGA schrieb im Beitrag #6840196:
> Hmmm dann ist aber seltsam das sie DC-50 Mbd und nicht die bandbreite
> DC-xxMHz spezifizieren.

Schau Dir z.B. den 6N137 an, der wird auf der ersten Seite auch mit 10 
MBaud beworben. Ist also gängig in dem Bereich das so zu machen. Wenn Du 
dann im Detail schaust, findest Du weiter hinten im Datenblatt auch 
Propagation Delays, Distortion, Risetimes etc.

> Nun UART mit 50mbaud?

Halte ich für ungeeignet für die Geschwindigkeit. Du wirst vermutlich 
Probleme mit Clock-Drift zwischen den Gegenstellen bekommen. Gustl 
schrieb ja auch dazu "wenn du was Einfaches suchst". Das geht halt nur 
bei Kompromissen bezügl. Geschwindigkeit. Bis vielleicht 10 MBit/s ist 
UART realistisch.

Schau daher lieber nach einer Codierung, bei der Du Takt und 
Datenwortgrenzen aus dem Datenstrom rückgewinnen kannst. Z.B. 8b10b wäre 
eine gängige Variante.

von FPGA (Gast)


Lesenswert?

Gerd E. schrieb:
> Schau daher lieber nach einer Codierung, bei der Du Takt und
> Datenwortgrenzen aus dem Datenstrom rückgewinnen kannst.

Hmmmpf da mache ich wohl eine Baustelle auf; aber ja mein zuvor 
erwähnter oversample Ansatz wird wohl der Holzweg sein.
Nun die Clk rückgewinnung sollte wohl mit Manchester am einfachsten 
sein, wobei NRZ-I mit anschliessend 8b10b der vermutlich besere weg.
Gibts möglichkeiten einen internen pll zur NRZI clk recovery zu nutzen? 
8b10b gibts anscheinend freie IP.

Was ich auch nicht ganz verstehe wie die synchronisation mittels 8b10b 
abläuft: wird von zeit zu zeit an K-wort gesendet welches das input 
shift register zurücksetzt?

von Gerd E. (robberknight)


Lesenswert?

FPGA schrieb im Beitrag #6840230:
> Nun die Clk rückgewinnung sollte wohl mit Manchester am einfachsten
> sein

Für Manchester geht aber 50% Deiner Bandbreite bei drauf. Bei 8b10b 
sinds nur 20%. Dafür steigt natürlich der Implementationsaufwand.

Wenn Du in der Praxis nur 10 MBit/s oder ein wenig mehr brauchst, kannst 
Du es mit UART versuchen und Dir den Aufwand sparen.

von FPGA (Gast)


Lesenswert?

Gerd E. schrieb:
> Bei 8b10b sinds nur 20%. Dafür steigt natürlich der
> Implementationsaufwand.

Was ich nicht verstehe, ist wie 8b10b die clk rückgewinnung macht. Alle 
cores die ich bisher gesehen haben haben entsprechend 10 bit und clk 
(rückgewonnen/10) als input.
Wird nicht zusätzlich noch NRZI (oder andere wie zb. Manchester) 
benötigt für die clkrückgewinnung. NRZI hat anscheinend den geringsten 
Bandbreitenoverhead.

Anscheinend habe ich hier noch ein verständissproblem, kann das bitte 
kurz wer klären wie genau das mit 8b10b implementierung gemeint ist?

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6840374:
> Was ich nicht verstehe, ist wie 8b10b die clk rückgewinnung macht.

Kommt auf die Umsetzung an, da gibt es viele Möglichkeiten.

> Alle
> cores die ich bisher gesehen haben haben entsprechend 10 bit und clk
> (rückgewonnen/10) als input.

Also muss das extern gemacht werden.

> Wird nicht zusätzlich noch NRZI (oder andere wie zb. Manchester)
> benötigt für die clkrückgewinnung.

Nein.

> Anscheinend habe ich hier noch ein verständissproblem, kann das bitte
> kurz wer klären wie genau das mit 8b10b implementierung gemeint ist?

Was meinst du denn genau? Man kann einen Datenstrom mit 8B10B kodieren, 
der ist dann a) gleichanteilfrei und b) hat eine relativ hohe 
Mindestfrequenz bzw. Mindestflankendichte. Sowas läßt sich leicht über 
AC gekoppelte Signalwege (Trafos, AC-gekoppelte optische Tranceiver) 
übertragen. Die CDR (clock and data recovery) ist dadurch auch relativ 
einfach. Wie das im Detail gemacht wird, kann ich dir nicht sagen, ist 
aber als Anwender auch egal. Dafür gibt es ICs bzw. Cores.

Dein Versatile Link (deutsch: Vielzweckverbindung) ist ja nur der 
Physical Layer, sprich, das reine Übertragungsmedium, hier Faseroptik. 
Da fehlt noch der Logical Layer, also die Kodierung etc. Das macht man 
dann mit  Manchester, 8B10B oder anderen Methoden, je nach Anforderung 
des Physical Layers. Da die Dinger anscheinend DC-50 Mbaud unterstützen, 
kann man sehr einfache Kodierungen nutzen, wie eben einen UART mit 10 
Mbaud. Darüber hinaus sollte man über andere Schnittstellen nachdenken, 
denn selbst wenn dein UART in deinem uC deutlich mehr schaffen sollte, 
ist das unpraktisch. Denn auch bei "nur" 10 Mbaud klingelt jede us der 
RX Interrupt. Jaja, mit DMA mag man das in den Griff kriegen, aber so 
richtig sinnvoll erscheint das nicht. Da würde ich eher auf Ethernet 
oder ähnliches gehen.

von Falk B. (falk)


Lesenswert?

Gerd E. schrieb:
>> Nun UART mit 50mbaud?
>
> Halte ich für ungeeignet für die Geschwindigkeit. Du wirst vermutlich
> Probleme mit Clock-Drift zwischen den Gegenstellen bekommen.

Wieso denn? UART toleriert relativ viel Taktfehler, je nach 
Betrachtungswinkel 1-3%. Wenn beide Teilnehmer einen Quarz als 
Taktquelle nutzen, ist das keinerlei Problem.

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6840230:
>> Schau daher lieber nach einer Codierung, bei der Du Takt und
>> Datenwortgrenzen aus dem Datenstrom rückgewinnen kannst.
>
> Hmmmpf da mache ich wohl eine Baustelle auf; aber ja mein zuvor
> erwähnter oversample Ansatz wird wohl der Holzweg sein.

Nein, ist es nicht. So arbeiten sehr viele Verfahren. UART nutzt eine 
16fach Überabtastung. USB mit Low (1,5Mbit/s) und Full Speed (12 Mbit/s) 
nutzt eine 4fach Abtastung. Mit eienr passenden FSM wird dann der Takt 
und die Daten zurück gewonnen.

von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> UART nutzt eine 16fach Überabtastung

Nun bei 50Mbaud sind dass dann 800MHZ abtastrate, kenne keinen uC oder 
FPGA der das handeln kann.
Wenn es jedoch gelingen würde diese überabtastung zu erreichen sollte 
doch theoretisch die baudrate keinen einfluss auf die 
übertragungsstabilität haben (abweichungen der clk frequenzen tx-rx).

Falk B. schrieb:
> Die CDR (clock and data recovery) ist dadurch auch relativ einfach. Wie
> das im Detail gemacht wird, kann ich dir nicht sagen, ist aber als
> Anwender auch egal. Dafür gibt es ICs bzw. Cores.

Hervorragend. Nun ein entsprechender core würde das problem für mich 
direkt lösen, hast du hier ein link? Ja bin auch nur anwender, ein tx 
und rx core die einen stabilen 20% overhead link bereitstellen und ich 
bin supper happy. (können gerne auch einen pll benötigen für die clk 
rückgewinnung)

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6840519:
> Falk B. schrieb:
>> UART nutzt eine 16fach Überabtastung
>
> Nun bei 50Mbaud sind dass dann 800MHZ abtastrate, kenne keinen uC oder
> FPGA der das handeln kann.

Wer betreibt denn einen UART mit 50 Mbaud? FPGAs schaffen das, wenn 
gleich sie dazu ggf. einen Hardcore brauchen. Außerdem kann UART auch 
mit 8x Überabtastung arbeiten, macht dann "nur" noch 400MHz. Mit DDR 
Abtastung nur noch 200MHz

> Hervorragend. Nun ein entsprechender core würde das problem für mich
> direkt lösen, hast du hier ein link? Ja bin auch nur anwender, ein tx
> und rx core die einen stabilen 20% overhead link bereitstellen und ich
> bin supper happy. (können gerne auch einen pll benötigen für die clk
> rückgewinnung)

Ich würde einen Hot-Link Tranceiver nehmen. Die sind ursprünglich für 
Video gedacht, haben somit ein 24+4 Bit Interfache + Takt. Nachteil sind 
die 4 differentillen Leitungen. Hmm, vermutlich gibt es das auch als 
Einzelsignal.

https://www.cypress.com/products/phys?id=138

Die Website ist im Moment ziemlich buggy, der scheint die Fusion mit 
Infineon nicht so bekommen zu sein.

P S Der Sender ist relativ einfach, da hab ich vor Ewigkeiten mal in 
einem Virtex FPGA gemacht (ja, der allererste Virtex, war so um 2003 
rum). Der Empfänger ist wegen der CDR deutlich aufwändiger, aber ich 
vermute, daß es da vor allem für die aktuellen FPGAs durchaus was gibt, 
zumal 50 Mbit/s nicht sooo wild sind. Ich kann dir aber keine konkreten 
Tips geben.

: Bearbeitet durch User
von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> Ich würde einen Hot-Link Tranceiver nehmen.

Hmmpf ist das nicht weit übers ziel hinaus geschossen? Hotlink können 
100e mbit und ein transceaver war um die 170 eur/stk wenn ich mich 
korrekt erinnere (lange her).

Am liebsten wäre mir ein communikationscore welcher ins fpga.

Falk B. schrieb:
> Wer betreibt denn einen UART mit 50 Mbaud?

Ja die idee habe ich ursprünglich auch als absurd angeschaut. Anyway mit 
dem Folgenden:

Falk B. schrieb:
> UART auch mit 8x Überabtastung arbeiten, macht dann "nur" noch 400MHz.
> Mit DDR Abtastung nur noch 200MHz

hast du mich auf die idee gebracht mit dem pll verschiedene phasenlagen 
des clk signals zu erstellen und die abtastung zu parealellisieren (kann 
dies in der praxis funktionieren)?

Eine gelungener communikationscore mit 8b10b o.ä. wäre vermutlich zu 
bevorzugen

von Falk B. (falk)


Lesenswert?

Channel Link von TI könnte passen, ist deutlich billiger.

https://www.ti.com/interface/other-interfaces/products.html#p1389=Channel-Link%20I;FPGA-Link

Hmm, geht nicht, die haben 3+1 differentielle Signale, nix mit 8B10B 
Kodierung.

Doch, der hier kann es, kommt aber nur auf 100Mbit/s runter.

https://www.ti.com/product/SN65LV1224B-EP

Der hier kann es, Channel Link II

https://www.ti.com/product/DS92LV0412

von FPGA (Gast)


Lesenswert?

Auf:

https://opencores.org/projects/8b10b_encdec

steht zb:

These cores can be easily incorporated into serializer/deserializer 
(serdes) communications applications.

Cores die 10b-8b und umgekehrt machen habe ich etliche gefunden. Anyway 
alle als vektor in und vektor out. Versteht jemand wie das mit serdes 
vereint werden kann?

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6840810:
> Auf:
>
> https://opencores.org/projects/8b10b_encdec
>
> steht zb:
>
> These cores can be easily incorporated into serializer/deserializer
> (serdes) communications applications.

Das ist ja auch trivial, das ist eine popelige Tabelle mit 256+ein paar 
Einträgen a 10 Bit.

> Cores die 10b-8b und umgekehrt machen habe ich etliche gefunden. Anyway
> alle als vektor in und vektor out. Versteht jemand wie das mit serdes
> vereint werden kann?

Einen Sender baut man auch trivial, ein simples parallel-seriell 
Schieberegister. 10 Bits rein, mit 10fachem Takt seriell raus. Geht bis 
viele hundert MHz mit modernen FPGAs, auch mit normaler Logik ohne 
Hardcore SerDes (GBit Tranceiver). Die Herausforderung ist der Empfänger 
mit CDR (clock & data recovery). Sagte ich bereits.

von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> Das ist ja auch trivial, das ist eine popelige Tabelle mit 256+ein paar
> Einträgen a 10 Bit.

falsch, ich meine nicht die 8b10b wandlung (da habe ich ja auch den vhdl 
code zu verlinkt) sondern der serdes (und ja insbesondere clk recovery 
und sync)

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6840989:
> falsch, ich meine nicht die 8b10b wandlung (da habe ich ja auch den vhdl
> code zu verlinkt) sondern der serdes (und ja insbesondere clk recovery
> und sync)

Das hab ich schon verstanden, aber ich kann dir auch keinen Link auf 
einen SerDes als FPGA Core bieten.

von Falk B. (falk)


Lesenswert?

Man könnte einen SerDes mit CDR für USB Full Speed suchen und den auf 50 
Mbit/s aufbohren. Es gibt auch in einigen USB Application Notes ein paar 
grundlegende Informationen dazu. Ich meine sogar, dort vor Jahren eine 
FSM dazu gesehen zu haben.

: Bearbeitet durch User
von Gustl B. (-gb-)


Lesenswert?

Falk B. schrieb:
> auch mit normaler Logik ohne
> Hardcore SerDes (GBit Tranceiver).

Auch die normalen SerDes in den IOs sind in Hardware vorhanden. Die kann 
man schlicht verwenden. 
https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf 
Seite 143.

Bisher hat "FPGA" aber noch gar nicht gesagt welche Datenrate er 
erreichen muss/will. Müssen das die 50 MBaud sein und du willst da 
möglichst viele Nutzdaten drüber bekommen?

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> Bisher hat "FPGA" aber noch gar nicht gesagt welche Datenrate er
> erreichen muss/will. Müssen das die 50 MBaud sein und du willst da
> möglichst viele Nutzdaten drüber bekommen?

Effektive nutzdaten würden 30-40mbit genügen, aktuell sinds 28.5 (etwas 
reserve habe ich immer gerne).
Badbreite habe ich aktuell die Spezifikation von Broadcom als 
limitierung genommen. Dabei ist mir unklar wie diese auszulegen ist 
(DC-50MBaud spezifiziert)(!)
Eigentlich müsste damit 50Mbaud erreicht werden overhead mit 
eingerechnet sein?!?

Also muss: 28.5, will: möglichst viel

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6841024:
> Also muss: 28.5, will: möglichst viel

Wozu dann die Sonderlocken? Nimm Fast-Ethernet, dafür gibt es 
tonnenweise IP oder auch ICs. Brutto macht das 125 Mbaud. Such dir einen 
passenden, optischen Tranceiver dafür und gut.

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6841024:
> Eigentlich müsste damit 50Mbaud erreicht werden overhead mit
> eingerechnet sein?!?

Baud ist die Symbolrate. Da gibt es nix mit Overhead.

FPGA schrieb im Beitrag #6841024:
> Also muss: 28.5, will: möglichst viel

Mehr als das geht schon durch mit passendem Encoding.

von Bernd G. (Gast)


Lesenswert?

Für die ganz Harten: CDR unter Verwendung des TLC2932
www.ti.com/lit/an/slaa011b/slaa011b.pdf
Bei Xilinx gibt es auch eine ca. 15 Jahre alte AN für eine CDR. Die 
Nummer dafür habe ich derzeit nicht bei der Hand. Das war in einer 
ganzen Sammlung von AN für Audio- und Videozeugs enthalten.

von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> FPGA schrieb:
>
>> Also muss: 28.5, will: möglichst viel
>
> Wozu dann die Sonderlocken? Nimm Fast-Ethernet, dafür gibt es
> tonnenweise IP oder auch ICs. Brutto macht das 125 Mbaud. Such dir einen
> passenden, optischen Tranceiver dafür und gut.

Hmmmpf da mache ich mir aber ne baustelle auf mit softcore, ipstack dann 
DMA um den softcore zu umgehen etc.
Also wenn du mit einen einfache IP hast wo ich einen Link FPGA pin - fo 
- FPGA pin hast welcher mir einen einfachen link erstellt und das 
einzige was ich machen muss ist fasteth FO transceiver einsetzen dann 
gerne

von Bernd G. (Gast)


Lesenswert?

Früher (TM) gab es einen hübschen Reclocker namens CLC016, der hat im 
angedachten Bitratenbereich Takt und Daten sauber herausgelegt. Es war 
einmal...

von Gustl B. (-gb-)


Lesenswert?

Hast du noch einen zweiten Kanal um einen Takt zu übertragen? Das könnte 
einiges erleichtern.
Aber auch sonst glaube ich, dass du da UART mit vollen 50 MBaud machen 
kannst. Der Takt der beiden FPGAs darf nur innerhalb einer Übertragung 
(8N1 oder so) nicht zuweit weglaufen.

Wenn du das ausgibst bei 50 MBaud, dann ist ein Bit 20 ns auf der 
Leitung.
Du gibst Startbit aus, dann die 8 Datenbits und lässt dann eine kurze 
Pause, auch Stoppbit genannt die mindestens eine Bitzeit lang sein muss.
Von Start bis zum letzten Bit sind das 9 Bits, die Übertragung dauert 
also insgesamt 180 ns.
Und nach der Pause/Stopbit geht es wieder mit dem Startbit los.

Sagen wir im Empfänger tastest du das mit 200 MHz ab (also eher langsam. 
Mit normalen SerDes bekommst du auch in günstigen FPGAs so um 1 GHz 
hin). Also 5 ns Auflösung. Im schlimmsten Fall erfasst du das Startbit 
fast einen ganzen Takt zu spät. Also grob 5 ns. Dann setzt du dich in 
die Mitte der Datenbits wobei du im schlimmsten Fall jetzt 5 ns neben 
der Mitte sitzt. Dann hast du noch 5 ns Spielraum. Sagen wir etwas 
weniger, 2 ns. Und um das dürfen die Takte der beiden FPGAs während der 
insgesamt 180 ns maximal driften. Grob maximal 1%. Und das ist 
hoffentlich locker zu machen. Taktgeber auf FPGA Boards und auch PLLs 
sind sehr viel stabiler.

Mein Fazit ist also da einfach mal UART zu machen. Wenn es funktioniert 
bekommst du 40 MBit/s Nutzdatenrate. Und wenn nicht, dann hast du was 
gelernt.

: Bearbeitet durch User
von Gerd E. (robberknight)


Lesenswert?

FPGA schrieb im Beitrag #6841059:
>> Wozu dann die Sonderlocken? Nimm Fast-Ethernet, dafür gibt es
>> tonnenweise IP oder auch ICs. Brutto macht das 125 Mbaud. Such dir einen
>> passenden, optischen Tranceiver dafür und gut.
>
> Hmmmpf da mache ich mir aber ne baustelle auf mit softcore, ipstack dann
> DMA um den softcore zu umgehen etc.

Nö, Falk hat nix von TCP/IP geschrieben, er hat Ethernet geschrieben. Du 
kannst problemlos Dein eigenes Protokoll über Standard-Ethernet 
übertragen und brauchst kein TCP/IP. Und wenn Du das ganz simpel 
gestaltest, geht das auch direkt auf dem FPGA und ohne Softcore. Du 
brauchst nur einen Ethernet-MAC und einen passenden PHY. Und musst die 
Daten dann in Pakete/Frames aufteilen.

Vorteil ist natürlich auch daß Du normale Ethernet-Infrastruktur 
verwenden kannst. Also Switche, Medienkonverter etc. Oft ist Ethernet 
schon vorhanden und wenn nicht dann gibt es eine große Auswahl an 
fertigen Komponenten für alle möglichen Anforderungen.

Von daher finde ich den Vorschlag eigentlich ziemlich gut.

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6841059:
>> Wozu dann die Sonderlocken? Nimm Fast-Ethernet, dafür gibt es
>> tonnenweise IP oder auch ICs. Brutto macht das 125 Mbaud. Such dir einen
>> passenden, optischen Tranceiver dafür und gut.
>
> Hmmmpf da mache ich mir aber ne baustelle auf mit softcore, ipstack dann
> DMA um den softcore zu umgehen etc.

Naja, ist auch wieder wahr. Aber man könnte den reinen PHY bzw. das MII 
(Media Independend Interface) von Ethernet nutzen, um zumindest die 
CDR-Funktion zu bekommen, damit man sie nicht selber im FPGA stricken 
muss.

https://de.wikipedia.org/wiki/Media_Independent_Interface

Sowas hier

https://www.ti.com/product/DP83822HF

Der macht die CDR und 8B10B Kodierung/Dekodierung.

> Also wenn du mit einen einfache IP hast wo ich einen Link FPGA pin - fo
> - FPGA pin hast welcher mir einen einfachen link erstellt und das
> einzige was ich machen muss ist fasteth FO transceiver einsetzen dann
> gerne

Hab ich nicht.

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> Sagen wir im Empfänger tastest du das mit 200 MHz ab (also eher langsam.
> Mit normalen SerDes bekommst du auch in günstigen FPGAs so um 1 GHz
> hin).

200MHZ abtastung kriege ich hin.
Wie ich den SerDes einsetze - da brauche ich eure Unterstützung.

von Gustl B. (-gb-)


Lesenswert?

FPGA schrieb im Beitrag #6841174:
> 200MHZ abtastung kriege ich hin.

Dann mach das - ganz ohne SerDes. Und wenn bei 200 MHz Fehler passieren, 
dann gehen ja nach FPGA auch 300 oder 400 MHz.

FPGA schrieb im Beitrag #6841174:
> Wie ich den SerDes einsetze - da brauche ich eure Unterstützung.

Kannst du machen, aber ich vermute dass du das nicht benötigst. Die 
Takte sind stabil genug. Das wäre die Notfalllösung wenn das so nicht 
geht.

Also ... schreibe einen UART der mit Überabtastung arbeitet. Das kann 
man auch gut simulieren, eigentlich ein schönes Thema um zu lernen.

von FPGA (Gast)


Lesenswert?

Gustl B. schrieb:
> schreibe einen UART

Wozu? gibts ja überall im internet rumliegend. Zb. hier

https://forum.digikey.com/t/uart-vhdl/12670

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6841367:
> Gustl B. schrieb:
>> schreibe einen UART
>
> Wozu? gibts ja überall im internet rumliegend. Zb. hier
>
> https://forum.digikey.com/t/uart-vhdl/12670

Naja. Die allermeisten UARTs sind mal sicher NICHT auf 200MHz++ 
Arbeitstakt ausgelegt . . .

von Bernd G. (Gast)


Lesenswert?

> Gem. Broadcom kann der DC-50Mbaud. Die frage ist wie?
Beim Lesen des Datenblattes wird es klar. Der Sender hat einen 
integrierten Treiber und der Empfänger eine integrierte 
Signalaufbereitung mit Logikausgang. Die 50 Mbaud können bis zu einer 
Leitungslänge von 50 m ausgereizt werden. Mit anderen Worten: bis zu 50 
m verhält sich das Ganze wie eine metallische Leitung. Nix Manchester, 
nix 8b/10b, nix UART, nix Reclocker. Was übertragen wird, ist der 
Leitung egal, es existieren weder  Forderungen nach NRZ-Signalen noch 
nach der Vermeidung von pathologischen Pattern, weil der Signalweg rein 
gleichspannungsmäßig ohne kapazitive Kopplungen läuft. Sozusagen ein 
langgezogener Optokoppler.

Im Zweifelsfall: Sender kaufen, 50 m Faser kaufen, Empfänger kaufen, 
alles in Reihe schalten und ausprobieren. Kostet ja nicht viel.

von FPGA (Gast)


Lesenswert?

Habs nun mal getestet. Nun den UART core habe ich auf 300mhz gebracht. 
Habs dann ebenfalls mit 450mhz probiert (negativer slack).
Ohne optische strecke: 100mbaud mit 300mhz läuft stabil. 450mhz 150mbaud 
läuft auch relativ gut gibt aber übertragungsfehler.

2 Cyclone 10LP FPGA mit jeweils eigenem oszillator.

Nun der timing analyzer sagt das das routing am meisten slack auffrisst. 
Kann man hier noch mehr machen als auf fmax optimieren?

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6846311:
> Nun der timing analyzer sagt das das routing am meisten slack auffrisst.
> Kann man hier noch mehr machen als auf fmax optimieren?

Naja, 300MHz ist schon VERDAMMT viel. Wenn es schneller gehen soll bzw. 
muss, muss man halt schauen, an welcher Stelle die größten 
Verzögerungszeiten auftreten. Vor allem, welche Logiktiefe dort erreicht 
wird. Man kann sicher ein paar Sachen optimieren, z.B. Zähler und state 
machines von binär auf one hot Kodierung umstellen, die sind schneller. 
Letzteres geht per Compilereinstellung, muss man nicht manuell machen. 
Man kann auch die Frage stellen, wie hoch die Überabtastung sein muss. 
Reicht x8 oder gar nur x6 oder x4?
Als weitere Option kann man den UART komplett neu machen und nur die 
reine Abtastung auf der sehr hohen Frequenz laufen lassen. Sprich, einen 
Seriell/Parallel Wandler mit 8:1 bauen und dann die Dekodierung 
gemütlich bei 50 MHz mit etwas mehr Logik durchführen.

von FPGA (Gast)


Lesenswert?

FPGA schrieb im Beitrag #6846311:
> Ohne optische strecke

Habs nun mit der Optischen strecke getestet. Die Verbindung ist nicht 
stabil. (Auch nicht bei tieferen  geschwindigkeiten 100k baud etc). Es 
scheint, dass er die synchronisation verliert (um bus idle zu vermeiden 
folgt startbit auf stoppbit)

von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> weitere Option kann man den UART komplett neu machen und nur die reine
> Abtastung auf der sehr hohen Frequenz laufen lassen. Sprich, einen
> Seriell/Parallel Wandler mit 8:1 bauen und dann die Dekodierung
> gemütlich bei 50 MHz mit etwas mehr Logik durchführen.

Nun evtl. muss ich mich auch von uart versbschieden. Leider musste ich 
feststellen dass mein FPGA Cyclone 10 LP kein Soft-CDR hat (also serdes 
einsetzen funktioniert nicht).

Anyway habe von xilinx ein paper gesenen aus dem jahr 2003 wo sie 
mittels pll phasen und ddr eine 8fache überabtastung erreichen. Danach 
könnte  doch 8b10b mit viterbi decoder gemacht werden.
Gibts da irgend einen core? Das ganze ist ja eigentlich basic FPGA-FPGA 
data transfer.

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6848359:
> Habs nun mit der Optischen strecke getestet. Die Verbindung ist nicht
> stabil. (Auch nicht bei tieferen  geschwindigkeiten 100k baud etc). Es
> scheint, dass er die synchronisation verliert (um bus idle zu vermeiden
> folgt startbit auf stoppbit)

Und gibt dem Empfänger im Falle eins Synchronisationsverlustes NIE mehr 
die Möglichkeit, sich zu synchronisieren. Fail!

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6848368:
> Anyway habe von xilinx ein paper gesenen aus dem jahr 2003 wo sie
> mittels pll phasen und ddr eine 8fache überabtastung erreichen. Danach
> könnte  doch 8b10b mit viterbi decoder gemacht werden.

Schon wieder Bullshit BINGO Zeit? Dein ach so toller Viterbi Codec löst 
dir dein CDR Problem keine Sekunde! Und wenn du nicht mal 1 Mbit/s UART 
über deine Strecke bekommst, musst du über 50Mbit/s keine Sekunde 
nachdenken.

> Gibts da irgend einen core? Das ganze ist ja eigentlich basic FPGA-FPGA
> data transfer.

Vielleicht von Ratiopharm? ;-)

: Bearbeitet durch User
von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> Dein ach so toller Viterbi Codec löst dir dein CDR Problem keine
> Sekunde!

Ok Wie mache ichs dass es über eine sekunde gelöst ist mit dem Cyclone 
10 LP?

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6848660:
> Falk B. schrieb:
>> Dein ach so toller Viterbi Codec löst dir dein CDR Problem keine
>> Sekunde!
>
> Ok Wie mache ichs dass es über eine sekunde gelöst ist mit dem Cyclone
> 10 LP?

Troll?

von FPGA (Gast)


Lesenswert?

Falk B. schrieb:
> Troll?

Anyway die Strecke ist wie gesagt eigentlich für 50mhz ausgelegt. Meine 
ZART implementierung läuft darauf nicht, aber das liegt vermutlich daran 
wie ich den UART betreibe (keine zeit zwischen stop und start).
Also ist es naheliegend; dass um das Synchronisationsproblem zu lösen 
auf ein anderes verfahren zurückgreife.
Habe mich dann bez Serdes schlaugemacht und musste lernen das mein FPGA 
kein CDR Serdes kann.

Nun gibts anscheinend seit annähernd 20jahren implementierungen die 
überabtastung mittels PLL phasenlage, und die synchronisatzion mittels 
8b10b zu erreichen.
Da ich das rad nicht neu erfinden möchte ist die Frage nach einem core 
doch legitim. Von dem her das einzige trollige ist, dass das thema 
eigentlich zunehmend in den FPGA bereich gehört.

von Falk B. (falk)


Lesenswert?

FPGA schrieb im Beitrag #6849000:
> Anyway die Strecke ist wie gesagt eigentlich für 50mhz ausgelegt. Meine
> ZART implementierung läuft darauf nicht, aber das liegt vermutlich daran
> wie ich den UART betreibe (keine zeit zwischen stop und start).

Das kann man ändern! Man kann alle X Bytes eine Pause von 10-20 Bit 
einlegen.

> Also ist es naheliegend; dass um das Synchronisationsproblem zu lösen
> auf ein anderes verfahren zurückgreife.

Nö. Man könnte den UART zum laufen bringen. Mindestens mit 1, eher 10 
Mbit/s. Dann kann man viel messen und testen. Und dann die sportliche 
HErausforderung von 50 Mbit/s angehen.

> Nun gibts anscheinend seit annähernd 20jahren implementierungen die
> überabtastung mittels PLL phasenlage, und die synchronisatzion mittels
> 8b10b zu erreichen.
> Da ich das rad nicht neu erfinden möchte ist die Frage nach einem core
> doch legitim.

Ja, aber die Antwort ist immer noch die gleiche. Ich habe keinen.

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.