Forum: FPGA, VHDL & Co. 8b10b mit CDR und frame detection Intel


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 Max M. (traffo)


Lesenswert?

Ich möchte über eine LWL-Kunstofffaser mit einer angeblichen Kapatzität 
von bis zu 200 mbit/s Daten übertragen.

Bei Xilinx giebts wenn ich mich korrekt erinnere die Aurora IP blocks 
welche den 8b10b CDR und auch die entsprechende Framesynchronisation 
machen.
Wie heisst dieser IP Block bei Intel?
Geht um eine FPGA-FPGA kommunikation (beides Intel)

von Antti L. (trioflex)


Lesenswert?

Wir ist dein LWL angeschlossen?
And FPGA normalen I/O oder den high speed transceiver.

Bei intel/Altera gibt es SerialLite der kann aber ab 622Mbit und 
schneller..

Bei 200Mbit must du glaube ich alles selber machen, auch den CDR was 
nicht so lustig sein wird. Mit "oversample" geht es schon, muss aber 
machen und sauber.

von Max M. (traffo)


Lesenswert?

Antti L. schrieb:
> And FPGA normalen I/O oder den high speed transceiver.

Ist aktuell differentiell vorgesehen (in der designphase und kann 
geändert werden).

Antti L. schrieb:
> Bei 200Mbit must du glaube ich alles selber machen, auch den CDR was
> nicht so lustig sein wird. Mit "oversample" geht es schon, muss aber
> machen und sauber.

Ich bin gerne bereit einen PLL dafür zu opfern. Selber machen übersteigt 
evtl. meine Fähigkeiten: Ein richtiges CDR mit PLL Pahsenregelung - kann 
meines wissens der Intel PLL - kenne ich mich überhaupt nicht aus.

Der Oversample approach mit verschiedenen Phasenlagen des PLLs? Sorgen 
macht mir insbesondere die Synchronisation bez des 8b10b Datenstroms. 
Selbst unter der suche nach den 12 special control characters, ist eine 
korrekte Synchronisation vermutlich nicht garantiert (Annahme 
kontinuierlicher Datenstrom). Dann Auswertung fehlerhafter 8b10b codes 
und dadurch korrekte Synchronisation herstellen(!)?

Hast du diesbezüglich evtl. code?

von Bernd G. (Gast)


Lesenswert?

Einen passenden Ethernet-Transceiver bzw Ethernet-PHY davorbinden.
Max M. schrieb:
> Ich möchte über eine LWL-Kunstofffaser

Über welche Länge soll es denn gehen?

von Antti L. (trioflex)


Lesenswert?

FPGA interne PLL's können kein CDR. OK, da gibt es einen trick wenn du 
viel bandbreite opfern willst:

dein TX teil generiert PWM mit 25% oder 75% für 0 und 1. Dann in RX hast 
du ein flip flop was 50:50 verhältnis erzeugt von dem PWM, das signals 
KANNST du jetzt an PLL geben, dann syncron mit dem PWM modulierten 
signal ist. Aber leider daten übertragungs rate niedrig, weil jeder bit 
4 time-units braucht. Das heist bei PHY raw data rate von 200Mbit (damit 
es durch LWL kommt) hast du benutzbare bit rate von 50Mbit :(

Dh oversampling ist einzige option, du kannst kleine stück code mit 
400Mhz takten, dann hast du mit DDR I/O flops eine datenrate von 800M, 
das reicht aus um den 200Mbit daten zu syncronieren. Etwas ähnliches 
wird gemacht bei soft IP cores für SGMII, da ist oversampling in spiel.

von Max M. (traffo)


Lesenswert?

Bernd G. schrieb:
> Über welche Länge soll es denn gehen?

Nur wenige meter, max 10m.

Bernd G. schrieb:
> Einen passenden Ethernet-Transceiver bzw Ethernet-PHY davorbinden.

Das bohrt das Problem aber ordentlich auf. Dann evtl. zuvor noch andere 
LWL TX/RX verwenden (zb. SFP) welche mit SerialLite IP gehen.

Aber este priorität wäre schon beim Avago Kunstoff zu bleiben und den 
CDR irgendwie (einfach) in HDL hinzukriegen.

von Gustl B. (gustl_b)


Lesenswert?

Max M. schrieb:
> Ist aktuell differentiell vorgesehen

Was willst du denn damit sagen? Sowohl LVDS mit normalen IOs als auch 
Transceiver arbeiten differentiell.

Max M. schrieb:
> Sorgen macht mir insbesondere die Synchronisation bez des 8b10b
> Datenstroms.

Wieso? Genau dafür gibt es die K Codes. Du musst nur die einzelnen Bits 
schön sauber erfassen und danach so hinslippen, dass da die korrekten 
Codes rausfallen.

Max M. schrieb:
> Selbst unter der suche nach den 12 special control characters, ist eine
> korrekte Synchronisation vermutlich nicht garantiert

Doch. Es gibt eindeutige Codes die man zum Training verwenden sollte.

Beitrag #7512242 wurde von einem Moderator gelöscht.
von Max M. (traffo)


Lesenswert?

Gustl B. schrieb:
> Wieso? Genau dafür gibt es die K Codes. Du musst nur die einzelnen Bits
> schön sauber erfassen und danach so hinslippen, dass da die korrekten
> Codes rausfallen.

Nun ich könnte doch um einige bits verrutscht sein: Dieser fehler 
geberiert mir ein gültiger K Code. Zufälligerweise generieren meine 
verschobenen Nutzdaten dann weitere korrekte K Codes. Und schon empfange 
ich Müll und denke das alles korrekt ist?!?
Ist es denn nicht nötig auf ungültige frames zu acheten?

Gustl B. schrieb:
> Doch. Es gibt eindeutige Codes die man zum Training verwenden sollte.

Nun es ist kein problem hin und wieder eine sequenz einiger K Codes zu 
senden. Selbst übertragungspausen wären möglich (minimale 
Bandbreitenfrequenz 1MHz).

von Gustl B. (gustl_b)


Lesenswert?

Max M. schrieb:
> Nun ich könnte doch um einige bits verrutscht sein: Dieser fehler
> geberiert mir ein gültiger K Code. Zufälligerweise generieren meine
> verschobenen Nutzdaten dann weitere korrekte K Codes. Und schon empfange
> ich Müll und denke das alles korrekt ist?!?

Nein.

Zum Zeitpunkt der Synchronisation haben da Nutzdaten nichts zu suchen. 
Da solltest du nur den K Code schicken und egal wie man den slippt, es 
gibt nur eine gültige Position. Das ist wunderbar eindeutig.
Erst wenn du den Code also stabil empfängst beginnst du mit den 
Nutzdaten. Und wenn da dann Fehler auftauchen trainierst du den Link 
neu.

Max M. schrieb:
> hin und wieder

Nein. Einmal am Anfang so lange bis das Training erfolgreich war. Danach 
sollte der Link stabil laufen. Wenn nicht hast du ein anderes Problem.

: Bearbeitet durch User
von Max M. (traffo)


Lesenswert?

Gustl B. schrieb:
> Zum Zeitpunkt der Synchronisation haben da Nutzdaten nichts zu suchen.

Ich habe keinen Uplink. Also der Sender kann nicht wissen ob die 
Synchronisation erfolgt ist.

von Gustl B. (gustl_b)


Lesenswert?

Dann kannst du tatsächlich zwischendrinnen ne Zeit lang den passenden K 
Code senden. Die Zeit muss eben ausreichen damit der Empfänger einmal 
komplett herumslippen kann. Ob du das jetzt zwischen sowas wie Paketen 
machst musst du wissen. Eigentlich sollte weiterhin einmal am Anfang 
reichen.

Eine unidirektionale FPGA zu FPGA Kommunikation stelle ich mir unnötig 
kompliziert vor. Die Dinger haben viele IOs.

von Bernd G. (Gast)


Lesenswert?

Max M. schrieb:
> Ich habe keinen Uplink. Also der Sender kann nicht wissen ob die
> Synchronisation erfolgt ist.

Lies dir die Patentschrift der Herren Widmer und Franaszek zum 
8b/10b-Code aufmerksam durch, dann weißt du auch, dass der Sender gar 
nichts wissen muss. Er muss lediglich ab und zu mal das Komma (K28.5) an 
der richtigen Stelle einfügen.
Die Nummer des Patents: US6977599. Inzwischen frei verfügbar; ich musste 
noch 30 USD dafür löhnen.
Es gibt noch ein älteres Patent hierzu: US4486739A, das ist offebar der 
Ursprung dazu.

von Bernd G. (Gast)


Lesenswert?

Was ich noch fragen wollte - die Rede ist von Plastikfaser im Kontext 
mit 200 Mbit/s. Gibt es da überhaupt irgendwelche passenden Sender und 
Empfänger?
Dass ich keine kenne, mag ja möglicherweise nichts bedeuten.

von J. S. (engineer) Benutzerseite


Lesenswert?

Max M. schrieb:
> Ich habe keinen Uplink. Also der Sender kann nicht wissen ob die
> Synchronisation erfolgt ist.

Aurora kann Vollduplex. Wenn du nicht bidirektional arbeiten möchtest 
oder kannst, löst man das per Protokoll: Der Empfänger dekodiert 
irgendwann im Strom einen vom Sender platzierten Umschaltbefehl und 
sendet nach einer Wartepause selbständig einen festgelegten Datensatz 
zurück, z.B. Status, erkannte Bandbreite, Zahl der Daten oder die Daten 
aus der Senke selber. Dann schaltet er wieder ab und der eigentliche 
Sender sendet wieder. Das macht man immer mal wieder und verifiziert so 
über die Zahl der empfangenen Daten, dass alles gefunden wurde. Im 
Protokoll kommt dann noch FEC und Redundanz.

Bernd G. schrieb:
> Gibt es da überhaupt irgendwelche passenden Sender und
> Empfänger?
Klar gibt es die. Sogar für Consumer: ADAT optisch geht z.B.  bis 
8-fache Frequenz, wenn man es richtig baut. Hat ein Kunde von mir mal 
eingesetzt. -> ~100MBit

von Christoph Z. (christophz)


Lesenswert?

Antti L. schrieb:
> Dh oversampling ist einzige option, du kannst kleine stück code mit
> 400Mhz takten, dann hast du mit DDR I/O flops eine datenrate von 800M,
> das reicht aus um den 200Mbit daten zu syncronieren.

Nicht zwingend, geht auch parallel mit 90° verschobenen Takten. Effekt 
ist der selbe, man hat 4 Samplingpunkte pro Clock.

Ich habe so etwas wie der TO sucht mal gebaut für einen unidirektionalen 
37.5 Mbit RS485 Link. Auch 8b10b codiert. Ich habe damals diese 
Präsentation als Orientierung genutzt:
https://www.presentica.com/hamzalind/low-cost-fpga-digital-phase-follower-deserializer-for-concentrated-serial-data-channels#

Entwicklungsaufwand als einziger FPGA Entwickler war mehrere Monate 
(CDR, 8b10b codierung, CRC, simulation, messen).
Läuft auch in der Nähe von >200 A/400 V schaltenden IGBTs.

: Bearbeitet durch User
von Max M. (fpga_eth)


Lesenswert?

Christoph Z. schrieb:
> Entwicklungsaufwand als einziger FPGA Entwickler war mehrere Monate
> (CDR, 8b10b codierung, CRC, simulation, messen).

Und Code möchtest du ungerne der Allgemeinheit zugänglich machen?

von Bernd G. (Gast)


Lesenswert?

Max M. schrieb:
> Und Code möchtest du ungerne der Allgemeinheit zugänglich machen?

Sein Cheffe würde das bestimmt nur ungerne sehen.

von Max M. (fpga_eth)


Lesenswert?

Bernd G. schrieb:
> Sein Cheffe würde das bestimmt nur ungerne sehen.

Wieso, geht ja nicht um was besonderes, also keine richtige IP mit 
firmengeheimnissen etc.

Ist ja nur data transfer, eigentlich jammerschade dass dies bei FPGAs so 
eine grosse Sache ist. Viele stehen vor basic data transferproblemen und 
beschäftigen sich mit dem Quatsch anstatt richtige IP zu machen.

Leider sind sie dazu gezwungen, das anscheinend keine freie IP 
diesbezöglich giebt.
Blame geht insbesondere an die Hersteller. Aber die kriegen die Quittung 
dafür viele FPGA interessierte aus Frust aufgeben.

Christoph Z. schrieb:
> Entwicklungsaufwand als einziger FPGA Entwickler war mehrere Monate
> (CDR, 8b10b codierung, CRC, simulation, messen).

Das zeigt doch wie absurd das Ganze ist. Ein KMU muss für mehrere Monate 
seinen einzigen FPGA Entwickler für ein Data Transfer Problem abbreufen.

: Bearbeitet durch User
von Gustl B. (gustl_b)


Lesenswert?

Max M. schrieb:
> Viele stehen vor basic data transferproblemen und beschäftigen sich mit
> dem Quatsch anstatt richtige IP zu machen.

Ist das so? Sowohl privat als auch beruflich mache ich das was du 
"richtige IP" nennst. Datenübertragung gehört aber eben auch dazu. Das 
ist oft der Grund wieso ein FPGA verwendet wird.

Max M. schrieb:
> Aber die kriegen die Quittung dafür viele FPGA interessierte aus Frust
> aufgeben.

Ja die Hobbybastler wobei das zumindest gefühlt mehr statt weniger 
werden in der FPGA Ecke. Aber an denen verdienen die Firmen sowieso 
kaum.

von Klaus K. (Gast)


Lesenswert?

Max M. schrieb:

>> Sein Cheffe würde das bestimmt nur ungerne sehen.
>
> Wieso, geht ja nicht um was besonderes, also keine richtige IP mit
> firmengeheimnissen etc.

Doch ist es, weil eben dem Entwickler über das Gehalt der Code abgekauft 
wurde, ist das jetzt Firmeneigentum.
Und solche Post wie 
Beitrag "Re: 8b10b mit CDR und frame detection Intel"

sind mindestens nah dran an der "Anstiftung zur Begehung einer Straftat" 
(§26 StGB reso. §111 StGB).

Und was soll das Getöse von "Allgemeinheit zugänglich machen"?! Die 
Allgemeinheit hat keinen FPGA zuhause, oder wäre intellektuell in der 
Lage, FPGA-Quelltexte sinnvoll einzusetzen.

von Christoph Z. (christophz)


Lesenswert?

Bernd G. schrieb:
> Max M. schrieb:
>> Und Code möchtest du ungerne der Allgemeinheit zugänglich machen?
>
> Sein Cheffe würde das bestimmt nur ungerne sehen.

Jepp, genau so. Ich würde da ja schon unter BSD oder (L)GPL stellen aber 
darf das nicht entscheiden.

Auf der anderen Seite kenne ich mittlerweile die Preise für SpaceWire 
oder IEEE1553 (MIL-BUS) IP cores. Da kann man auch mal 3 Monate 
entwickeln für (ob es sich lohnt, Risiko überschaubar ist oder sinnvoll 
ist, muss jede Firma selber entscheiden).

von Max M. (fpga_eth)


Lesenswert?

Klaus K. schrieb:
> Doch ist es, weil eben dem Entwickler über das Gehalt der Code abgekauft
> wurde, ist das jetzt Firmeneigentum.

Ja ist es.
Aber eine Grundlage für einen zivilrechtlichen Prozess ist ein 
entstandener Schaden, welche durch die "unbefugte Veröffentlichung des 
Teilquellcodes" entsehen würde. Da aber aus der Diskussion hervorgeht, 
dass diese IP nicht das Produkt der Firma ist, und ebenfalls keiner 
Konkurenz hillft (Annahme Firma erstellt irgend ein Industireprodukt, 
der Datentransfer ist nur Nebensache). Entstünde kein Schaden.
Des weiteren ist es wie gesagt nur daten transfer, ohne 
Produktspezifische infos/Firmengeheimnisse.


Klaus K. schrieb:
> sind mindestens nah dran an der "Anstiftung zur Begehung einer Straftat"
> (§26 StGB reso. §111 StGB).

Nun dies ist aber seeeehr weit hergeholt. Erstens ist es unklar obs 
wirklich eine richtige Straftat wäre wenns ohne einverständniss der 
Firma wäre.
Anyway diese "Anstiftung" bezieht sich natürlich auf veröffentlichung 
mit Einverständniss der Firma. Wie gesagt, ist nur Datentransfer, sehe 
nicht wie der Firma eine Veröffentlichung Schaden könnte.
Es werde gerichtet werden. Etwas womit wir deutschen uns (leider) je 
längers je mehr beschäftigen.

Das kommt auch schon ans nächste was ich FPGAs nerft: Das ganze IP getue 
überall, selbst wenn man einen für zig k EUR einen IP kauft und dieser 
dann nicht läuft und einen Fehlercode ausgiebt welcher dem Hersteller 
selbst nicht mal bekannt ist, erhält man keinen Quellcode :-(.

Christoph Z. schrieb:
> Jepp, genau so. Ich würde da ja schon unter BSD oder (L)GPL stellen aber
> darf das nicht entscheiden.

Danke!
Wäre dies echt ein Problem? Da du ja der einzige FPGAler bist, gehe ich 
davon aus, dass es ein KMU. Cheffe schon gefragt?

> Auf der anderen Seite kenne ich mittlerweile die Preise für SpaceWire
> oder IEEE1553 (MIL-BUS) IP cores. Da kann man auch mal 3 Monate
> entwickeln für (ob es sich lohnt, Risiko überschaubar ist oder sinnvoll
> ist, muss jede Firma selber entscheiden).

Es ist einfach nur zum heulen. Den Pingpongs schadets nicht gross die 
können günstig 2-3 Jungs einige Monate anstellen die irgend ein 
Datentransfer quatsch coden. Den Deutschen KMUs fliegt sowas um die 
Ohren, und wenn sies gelöst haben wird die Lösung auch nicht geteilt 
damit ist auch Sichergestellt, dass die anderen KMU dieses Rad selbst 
ebenfalls neu erfinden müssen.

: Bearbeitet durch User
von Gustl B. (gustl_b)


Lesenswert?

Max M. schrieb:
> was ich FPGAs nerft: Das ganze IP getue überall, selbst wenn man einen
> für zig k EUR einen IP kauft und dieser dann nicht läuft und einen
> Fehlercode ausgiebt welcher dem Hersteller selbst nicht mal bekannt ist,
> erhält man keinen Quellcode :-(.

Doch klar, wenn man den IP (oder eher das IP) als Quelltext gekauft hat. 
Kostet oft mehr.

Max M. schrieb:
> und wenn sies gelöst haben wird die Lösung auch nicht geteilt damit ist
> auch Sichergestellt, dass die anderen KMU dieses Rad selbst ebenfalls
> neu erfinden müssen.

Na herzlich willkommen in der Marktwirtschaft! Dein Bäcker 
veröffentlicht seine Rezepte auch nicht.

von Bernd G. (Gast)


Lesenswert?

Max M. schrieb:
> Den Deutschen KMUs fliegt sowas um die
> Ohren, und wenn sies gelöst haben wird die Lösung auch nicht geteilt
> damit ist auch Sichergestellt, dass die anderen KMU dieses Rad selbst
> ebenfalls neu erfinden müssen.

Und warum sollte ich mir selbst schaden, indem ich irgendwelchen 
Nassauern aufs Pferd helfe?

von Gustl B. (gustl_b)


Lesenswert?

Er kann auch an seinen Anforderungen schrauben.

Statt CDR kann er eine Taktleitung planen.
Und weil das sowieso unidirektional ist kann er auch UART machen. Ja, 
richtig. UART 8N1 mit 200 MBit/s und differentiell. Am Empfänger holst 
du die Bits dann mit einem SerDes raus. Also fallende Flanke vom 
Startbit erkennen und danach ist bekannt welche Bits verwendet werden 
müssen.

von Max M. (fpga_eth)


Lesenswert?

Gustl B. schrieb:
> Ja,
> richtig. UART 8N1 mit 200 MBit/s und differentiell. Am Empfänger holst
> du die Bits dann mit einem SerDes raus.

Umso besser wenns der Datentransfer stabil läuft ists mir eig. egal wie. 
Hast du entsprechende Serdes IP?

von Max M. (fpga_eth)


Lesenswert?

Gustl B. schrieb:
> Max M. schrieb:
>> und wenn sies gelöst haben wird die Lösung auch nicht geteilt damit ist
>> auch Sichergestellt, dass die anderen KMU dieses Rad selbst ebenfalls
>> neu erfinden müssen.
>
> Na herzlich willkommen in der Marktwirtschaft! Dein Bäcker
> veröffentlicht seine Rezepte auch nicht.

Ja, gutes bsp., denn die Becker gehen ja auch nicht reihenweise Pleite 
:P
Zumindest die mit eigenem Rezept, den Aufbäckern (know how geteilt) 
gehts hervorragend.

von Klaus K. (Gast)


Lesenswert?

>> richtig. UART 8N1 mit 200 MBit/s und differentiell. Am Empfänger holst
>> du die Bits dann mit einem SerDes raus.
>
> Umso besser wenns der Datentransfer stabil läuft ists mir eig. egal wie.
> Hast du entsprechende Serdes IP?

Bei allen Respekt, warum suchst Du Dir nicht eine Beschäftigung, die 
weder deine finanziellen noch deine intellektuellen Fähigkeiten 
überschreitet?!

So ein SerDes ist nun wirklich kein Hexenwerk, da findet sich der Code 
dafür in Anfängertutorials, bspw: 
https://github.com/ishfaqahmed29/SerDes/blob/main/piso_10bit.v

Wer danach in einem Forum schnorren muß, für den ist FPGA-Entwicklung 
wirklich die falsch Wahl.

von Bernd G. (Gast)


Lesenswert?

Gustl B. schrieb:
> Statt CDR kann er eine Taktleitung planen.

Er könnte auch einen CDR-Schaltkreis wie den SY69753ALHG (Digikey hat 
welche) nehmen und seine Schaltung drumherum bauen.

von Max M. (fpga_eth)


Lesenswert?

Klaus K. schrieb:
>>> richtig. UART 8N1 mit 200 MBit/s und differentiell. Am Empfänger holst
>>> du die Bits dann mit einem SerDes raus.
>>
>> Umso besser wenns der Datentransfer stabil läuft ists mir eig. egal wie.
>> Hast du entsprechende Serdes IP?
>
> Bei allen Respekt, warum suchst Du Dir nicht eine Beschäftigung, die
> weder deine finanziellen noch deine intellektuellen Fähigkeiten
> überschreitet?!

Nun, war teils ironischer Natur, da ich sehr skeptisch bin dass UART auf 
der gesch. stabil läuft.

Klaus K. schrieb:
> So ein SerDes ist nun wirklich kein Hexenwerk, da findet sich der Code
> dafür in Anfängertutorials, bspw:
> https://github.com/ishfaqahmed29/SerDes/blob/main/piso_10bit.v

Nun 1. Danke fürs Schieberegister, und 2. das wird vermutlich mit HDL 
nix für 200Mbaud. Keine Sorge die Hard Intel IP für den Serdes kenn ich.

Aber: denkt ihr wirklich, dass dies stabiel laufen könnte? Scheint mir 
etwas murks. 8B10B mit entsprechender CDR erscheint mir überlegen.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Max M. schrieb:
> Aber: denkt ihr wirklich, dass dies stabiel laufen könnte? Scheint mir
> etwas murks. 8B10B mit entsprechender CDR erscheint mir überlegen.

was hier irgendwer denkt, was stabieeeeel laufen koennte, ist doch 
voellig irrelevant. Entscheidend ist, das du das irgendwie hinkriegen 
solltest...
Und da hab' anscheinend nicht nur ich leichte Zweifel dran.

scnr,
WK

von Gustl B. (gustl_b)


Lesenswert?

Max M. schrieb:
> Umso besser wenns der Datentransfer stabil läuft ists mir eig. egal wie.
> Hast du entsprechende Serdes IP?

Wieso IP? Bei Xilinx kann man den SerDes wunderbar als Komponente 
instanttieren. Man muss ne PLL einstellen und anschließen und dann ist 
man schon fertig. Es fallen parallel die Bits raus.

Deine Aufgabe - nein dazu habe ich keinen IP - ist es den Anfang vom 
Startbit zu erkennen und dann in den bekannten Abständen einzelne Bits 
rauszuholen die dein Datenbyte ergeben.

Bernd G. schrieb:
> Er könnte auch einen CDR-Schaltkreis wie den SY69753ALHG (Digikey hat
> welche) nehmen und seine Schaltung drumherum bauen.

Dass es genug Möglichkeiten gibt ist glaube ich klar. Ich würde mich da 
zuerst ohne Hardware hinsetzen und das so bauen dass es in der 
Simulation läuft. Und dann mit Evalboards. Alles nicht irre komplex.

von Max M. (fpga_eth)


Lesenswert?

Gustl B. schrieb:
> Deine Aufgabe - nein dazu habe ich keinen IP - ist es den Anfang vom
> Startbit zu erkennen und dann in den bekannten Abständen einzelne Bits
> rauszuholen die dein Datenbyte ergeben.

Ja wenn ich hin und wieder 1Byte Pause zur Synchronisation einlege, ists 
wirklich einfach. Man suche die startbitflanke im Vektor vom Serdes und 
nehme jeweils die bits alle 1/Baud s. Sollte ich noch hinkriegen, danke 
für die bedenken.

Aber UART auf 200MBaud klingt für mich absurd?!
Und falls dies so einfach gehen sollte: Wieso wird dann in der Industrie 
8b10b CDR etc genutzt?

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Max M. schrieb:
> Wieso wird dann in der Industrie
> 8b10b CDR etc genutzt?

Weil "die Industrie" das im Gegensatz zu dir kann?

scnr,
WK

von Klaus K. (Gast)


Lesenswert?

> Aber UART auf 200MBaud klingt für mich absurd?!

Du kannst nicht richtig "hören", da wurde von 200 Mbit/s geschrieben und 
nicht von 200 MBaud/s. Bitrate ungleich Symbolrate.


Beitrag "Re: 8b10b mit CDR und frame detection Intel"

https://de.wikipedia.org/wiki/Baud#Verwechslung_mit_der_Bitrate

Und selbstverständlich geht es auch höher, siehe Datentransferraten 
aktueller DDR-Memory Interface. An den MGT (MultiGigabitTransceiver) 
sogar noch höher.

von Bernd G. (Gast)


Lesenswert?

Der TO hat sich längst vom Acker gemacht.

von Gustl B. (gustl_b)


Lesenswert?

Max M. schrieb:
> Ja wenn ich hin und wieder 1Byte Pause zur Synchronisation einlege, ists
> wirklich einfach.

Wieso 1 ganzes Byte Pause? Da kommt das Stoppbit und dann wieder ein 
Startbit. Da bekommt man wunderbar viel Durchsatz.

Max M. schrieb:
> Wieso wird dann in der Industrie 8b10b CDR etc genutzt?

Weil das in vielen Standards eben so vorgegeben ist und weil die 
Bitraten so hoch sind, dass man das nicht deutlich überabtasten kann.

Aber zwischen FPGAs wird alles Mögliche gesprochen. Hängt sehr von der 
Anwendung ab. Du kannst da auch SPI machen oder 4B5B, 64B66B, Manchester 
oder sonst was.
Das Wichtigste an jedem Projekt sind aber erstmal die Anforderungen 
herauszufinden. Brauchst du die 200 MBit/s oder reichen auch 10 Mbit/s?
Und erst im zweiten Schritt suchst du dann das aus was passt.

von J. S. (engineer) Benutzerseite


Lesenswert?

Max M. schrieb:
> Klaus K. schrieb:
>> Doch ist es, weil eben dem Entwickler über das Gehalt der Code abgekauft
>> wurde, ist das jetzt Firmeneigentum.
> Ja ist es, Aber eine Grundlage für einen zivilrechtlichen Prozess ist
> ein entstandener Schaden, welche durch die "unbefugte Veröffentlichung
> des Teilquellcodes" entsehen würde.

Der entstandene Schaden ist vor allem der, dass die Firma dir das Geld 
bezahlt hat und die IP dann an eine Fremdfirma geht, die nichts 
investieren muss und damit einen Wettbewerbsvorteil hat. Will man so 
argumentieren, kann man alles an andere weitergeben, was nicht materiell 
ist, weil es ja nicht verschwindet.

Der Sachverhalt hier ist auch zudem der, dass nicht die IP des 8b10b 
verkauft wird, sondern das ganze Gedöhns drum herum. Da ist regelmäßig 
viel zu tun, bis die Daten so verpackt sind, dass man sie dem Core 
übergeben kann. Es muss ja ein Protokoll gestrickt werden, das technisch 
funktioniert und funktionell zur Aufgabe passt. Das darf man 
selbstredend nicht posten, ich sehe da aber auch keinen Vorteil, weil da 
ohnehin niemand durchsteigen würde.

Die Funktion des 8b10b ist frei verfügbar und kann von jedem eingesetzt 
werden. Ob aber der Code, den man sich jeweils irgendwo runterlädt, von 
denen es unterschiedliche Implementierungen (z.B. auf OpenSoure, GIT) 
gibt, dann auch frei verfügbar ist und kommerziell genutzt werden darf, 
steht in den Bedingungen.

Wieder anders ist es bei der Aurora-Implementierung vom XI: Da steckt 
noch viel mehr dahinter (was man u.U. nicht braucht) was aber an die 
Funktion (rechtlich wie technisch) von XI geknüpft ist.

Dass es Leute gibt, die sich Teile des Aurora-Codes, als er noch nicht 
verkrüppelt, verschlüsselt und verhackstückt war, geschnappt haben, um 
ihn in ihren eigenen Projekten zu verwenden, steht auf einem anderen 
Blatt. Sowas soll vorkommen, aber posten tun die das hier ganz sicher 
nicht. :-)

von J. S. (engineer) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> Max M. schrieb:
>> Wieso wird dann in der Industrie 8b10b CDR etc genutzt?
>
> Weil das in vielen Standards eben so vorgegeben ist und weil die
> Bitraten so hoch sind, dass man das nicht deutlich überabtasten kann.

... und weil es eben auch aus strategischer Sicht keinen Sinn macht, 
einen Leitungscode zu verwenden, der eben diese spezielle Möglichkeit 
durch seine spektralen Eigenschaften erlaubt, um es dann nicht zu 
nutzen. Oder anders herum: Warum baut man überhaupt einen Leitungs-Code 
ein?

Es geht ja um die spektrale Verteilung und Redundanz. Eine der Optionen 
bei der Redundanz ist dann eben die Chance, den Takt einfach(er) zu 
rekonstruieren. Lässt man das ungenutzt, bleibt (nur) der Vorteil der 
spektralen Verschiebung, d.h. das Signal wird "AC-tauglicher" und kann 
(besser) per Übertrager oder kapazitiv übermittelt werden.

Treibt man es hingegen auf die Spitze, dann übermittelt man mit 
praktisch jedem Datentakt das Taktsignal, wie bei S/PDIF oder eben wie 
bei ...

Gustl B. schrieb:
> Manchester oder sonst was.

... genau. BMC (S/PDIF) ist die uneheliche Halbschwester vom Manchester 
und wird oft mit rein elektromagnetischen Übertragern im Audio-Bereich 
benutzt. Man kriegt ein ausreichend eng begrenztes Spektrum, praktisch 
ohne DC-Anteil, einen super guten Takt, der sehr eng an den Daten liegt 
- hat dafür halt nur die halbe maximale Rate im Bezug auf die verfügbare 
Bandbreite.

von J. S. (engineer) Benutzerseite


Lesenswert?

Max M. schrieb:
> Aber: denkt ihr wirklich, dass dies stabil laufen könnte? Scheint mir
> etwas murks. 8B10B mit entsprechender CDR erscheint mir überlegen.

Theoretisch richtig, wenn man die maximalen Raten vergleicht. Die ist 
bei SERDES aber höher, weil unabhängig von Leitungscode, bis zur 
maximalen Bandbreite gearbeitet werden kann. Man muss also schauen, was 
man vergleicht. Diese höhere Rate wird im anderen Fall erst einmal nicht 
erreicht.

Beim SERDES ist der Jitter höher, ja, aber solange man eine PLL hat, die 
den (mitgelieferten) Takt gut genug rekonstruiert, reicht es bis zu 
einer gewissen Zahl von Bits aus. Z.B. wird HDMI mit 10 Bits übertragen, 
während die PLL nur 1/10 des Taktes sieht. Würde man probieren, aus den 
angelieferten Videodaten den Takt zu rekonstruieren, hätte man sicher 
mehr Jitter auf Bit-Ebene und es würde über größere Stecken schwieriger.

Nur, wenn die Leitungscodierung deutlich besser ist, als das 
PLL-Verhälnis (hier 1:10), z.B. bei 4b5b, kann man erwarten, dass 
selbiger schneller die Clock rekonstruieren hilft und man näher dran ist 
an gestörten und gejitterten Bits.

Mit Bezug auf das oben Gesagte, ist die Aussage, dass CDR besser ist, 
(nur) dann richtig, wenn man diese Grenze unterschreitet, wie eben beim 
erwähnten Manchester / BMC. Damit bekommt man den qualitativ besseren 
Takt über die Leitung, wenn man sich an der maximalen slew rate der 
Leitung orientiert und Reflektionen einkalkuliert. Dann aber sinkt 
zunehmend das Verhältnis von Nutzdaten zu Leitungsdaten. Beim Manchester 
ist das dann 50%.

Geht man von der maximalen Bandbreite aus und fragt, wie man dabei am 
meisten Daten rüberkriegt, ist es aber besser, man steckt alles in die 
Daten und liefert noch einen Takt mit. Der hat die gleiche slew rate, 
eine geringere Frequenz, kann somit gut einen Schmitt-Trigger-Eingang 
aussteuern, dann mit einer PLL bearbeitet und hochtransformiert werden. 
Die PLL folgt dann immer noch genügend gut, um auch jitternde Daten noch 
einigermassen sicher zu lesen. Faktor 4 geht praktisch immer, Faktor 8 
so gut wie immer und im Einzelfall packt man auch Faktor 20. Wenn man 
die interne PLL aus einem rekonstruierten Takt füttern will, ist das 
problematischer.

von J. S. (engineer) Benutzerseite


Lesenswert?

Gustl B. schrieb:
> Das Wichtigste an jedem Projekt sind aber erstmal die Anforderungen 
herauszufinden.

Genau, erst wenn klar ist, ob die Daten oder der Takt wenig gestört 
werden können und auch wenig stören ist evident, ob man einen 
Leitungscode braucht, einen Scrambler und ob man ein bidirektionales 
Protokoll fahren muss und unbedingt eine Taktrekonstruktion im Empfänger 
braucht. Gerade beim Leitungs-Code-Überhang und Nutzen des Scramblers 
sind im Bezug auf das Thema Störungen auf Bussen bei einigen 
Entwicklern, die das munter einsetzen und weglassen, die Zusammenhänge 
nicht so ganz klar. Protokoll, Scrambling, Code und Details der 
Elektronik sollten möglichst zusammenpassen :-)

Christoph Z. schrieb:
> Entwicklungsaufwand als einziger FPGA Entwickler war mehrere Monate
> (CDR, 8b10b codierung, CRC, simulation, messen).
> Läuft auch in der Nähe von >200 A/400 V schaltenden IGBTs.
Wie schnell? War Manchester keine Alternative?
Die Taktik bei derartigen Störungen wäre ja die Einengung des 
Frequenzbereiches auf ein sehr schmales Band mit eben nur 2 wesentlichen 
Frequenzen, die dann sehr störsicher filterbar sind.
Im Gegensatz dazu ist 8b10b je wesentlich breitbandiger (störbar).

von Christoph Z. (christophz)


Lesenswert?

J. S. schrieb:
>> (CDR, 8b10b codierung, CRC, simulation, messen).
>> Läuft auch in der Nähe von >200 A/400 V schaltenden IGBTs.
> Wie schnell? War Manchester keine Alternative?
> Die Taktik bei derartigen Störungen wäre ja die Einengung des
> Frequenzbereiches auf ein sehr schmales Band mit eben nur 2 wesentlichen
> Frequenzen, die dann sehr störsicher filterbar sind.
> Im Gegensatz dazu ist 8b10b je wesentlich breitbandiger (störbar).

Interessanter Punkt mit den Spektraleneigenschaften von 
Manchester-codierung. War mir damals nicht bewusst, werde mir das aber 
mal merken.

Es sind zwei parallele Links mit je 25 MBaud/s über L3685-1E: 40 Mbps 
Isolated RS485 Transceiver von NVE. Simplex, nur Kommunikation vom 
Reglermaster zu Slaves. Macht so etwa 14 m über CAT5 (Die versprochenen 
40 Mbit gibts bei wesentlich kürzeren Kabeln). Anzahl Teilnehmer eher 
irrelevant, dominant ist die Kabellänge in diesem Design/PCB Layout.

8b10b ist ziemlich praktisch weil man gleich mehrere Sachen bekommt, die 
auch genutzt werden:
- AC frei
- Clock recovery
- K Symbole für Start/End of frame
- K Symbol für Idle um den CDR aktiv zu halten
- K Symbol für einen Time Trigger -> Speist eine Software PLL im DSP um 
alle PWM Generatoren im Gesammtsystem zu synchronisieren.

Die anderen K Symbole werden nicht genutzt.

Wurde so gebaut, weil nichts was wir am Markt gefunden hatten oder 
irgendwo Standartisiert ist, die von uns geforderten garantiert kurzen 
Latenzen konnte.

von J. S. (engineer) Benutzerseite


Lesenswert?

Christoph Z. schrieb:
> Es sind zwei parallele Links mit je 25 MBaud/s

Mit S/PDIF übertragen wir 2x24.576 MHz über RS422 (als AES EBU) über 
>100m.  Die Frage ist natürlich, was mit der Einstreuung von Außen ist. 
In einem Industrierumfeld habe ich das mal realisiert, waren damit 
einfache Audio-Chips. Aber die Störungen waren damals nicht in 
unmittelbarer Nähe.

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.