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)
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.
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?
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?
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.
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.
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.
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).
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
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.
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.
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.
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.
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
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
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?
Max M. schrieb: > Und Code möchtest du ungerne der Allgemeinheit zugänglich machen? Sein Cheffe würde das bestimmt nur ungerne sehen.
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
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.
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.
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).
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
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.
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?
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.
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?
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.
>> 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.
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.
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.
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
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.
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?
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
> 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.
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.
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. :-)
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.
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.
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).
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.