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?
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
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.
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.
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.
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?
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.
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?
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.
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.
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.
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)
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
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
Channel Link von TI könnte passen, ist deutlich billiger. https://www.ti.com/interface/other-interfaces/products.html#p1389=Channel-Link I;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
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?
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.
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)
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.
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
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?
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
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.
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.
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.
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
Früher (TM) gab es einen hübschen Reclocker namens CLC016, der hat im angedachten Bitratenbereich Takt und Daten sauber herausgelegt. Es war einmal...
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
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.
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.
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.
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.
Gustl B. schrieb: > schreibe einen UART Wozu? gibts ja überall im internet rumliegend. Zb. hier https://forum.digikey.com/t/uart-vhdl/12670
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 . . .
> 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.
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?
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.
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)
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.
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!
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
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?
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?
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.
FPGA schrieb im Beitrag #6849500: > 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.
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.