Ich möchte Daten von einer Baugruppe in die nächste übertragen. Die erste hat einen ARM7 mit konventionellem Bus und darf einen PLD/FPGA bekommen. Es stehen aber nur 2 Leitungen zur Verfügung. Länge geschätzt 25cm. Kabel, wie ich möchte. Nun stehe ich vor der Frage, eine SDO-Leitung zu nehmen und eine Taktleitung, oder es differenziell und dafür schön schnell aufzubauen. EMV-technisch geht beides. Bis zu welcher Datenrate kriege ich aus einem nicht genau bekannten Takt noch einen stabilen Datenstrom? Angesehen habe ich mir unterschiedliche Protokolle, die aber z.T. einen Takt benötigen oder rekonstruieren. Was nimmt man da am Besten und wie gestaltet man das Protokoll? Momentan wäre es 100% unidirektional vom Master zu dem Slavegerät. Bisher angedacht war ein einfaches, asynchrones Protokoll und eine UART draufzusetzen. Angenommen der PLD läuft mit 150 MHz, dann könnte man wegen oversampling vlt. 60Mbps hinbekommen und bei einem 11-12 Bit Protokoll folglich 5MBps. Das ist aber zu wenig. Auch ein 300 MHz FPGA würde nicht reichen. 50MB/s wären angestrebt. Laut Datenblatt können das die Serializer, aber ich frage mich, wie das mit dem Eintakten läuft: Ein Serializer für 50MB/s müsste sicher auf 500Mbps laufen. Wie synchronisiert man die dafür nötige PLL im Empfänger? Die beiden Baugruppen werden zwar aus dem gleichen Quarz versorgt, aber das hat 25MHz. Da wird es nicht gelingen, eine feste Taktkonstellation zu erzielen, die man einmal einstellt und die dann dauerhaft in der Mitte der Bits arbeitet. Transceiver wären mir zu aufwändig. Dann würde ich eher auf USB gehen.
Ist das unidirektional? Wenn ja dann würde ich zuerst Clock und SDO ausprobieren. Sehr wahrscheinlich bekommst du so schon >100 MBit/s hin. Am Empfänger dann dem Empfangsteil mit der Clock takten. Damit auch dekodieren und die Daten dann in einem Dual-Clock FIFO schreiben.
Wahrscheinlich, aber 100 MBit reichen nicht. 40MB * 8 = 320 wären wohl das Mindeste. Es läuft wohl auf eine synchrone Übertragung mit Taktrekonstruktion auf der Empfängerseite hinaus.
Moin, Heiko E. schrieb: > aber ich frage mich, wie das > mit dem Eintakten läuft: Ein Serializer für 50MB/s müsste sicher auf > 500Mbps laufen. Wie synchronisiert man die dafür nötige PLL im > Empfänger? Frag' halt nicht dich, sondern frag' die entsprechende Applicationnote fuer dein FPGA. Da gabs iirc vor langer Zeit z.b. mal die XAPP1064 fuer Spartan6, sowas wirds wohl auch fuer dein geheimes FPGA geben. Gruss WK
Das "geheime FPGA" wäre vorzugsweise ein Spartan 7 - ich wäre aber in der Auswahl frei. Es wäre also Teil der Antwort, welche FPGA Type man nimmt. Wahrscheinlich sollte ein klitzekleiner für weniger Euro reichen. Mir geht es derzeit um die Spezifikation: Es muss definiert werden, wie ein Protokoll auszusehen kann und mit welchen Takten und Randbedingungen es arbeitet, damit klar ist, was einzuhalten ist, um die Bandbreite zu schaffen. Soweit ich die Serializer verstehe, setzen die von einer tiefen Taktfrequenz auf z.B. das 8-fache hoch. Ich habe Probleme, mir vorzustellen, ob das an zwei Punkten ausreichend genau ist, wenn ich jeweils von 25 MHz ausgehe. Darüber macht die XAPP1064 z.B. auch keine klare Aussage. Angenommen, man lässt das auf 500MHz laufen, stehen gerade 2ns pro Takt zur Verfügung. Das wäre mit gut Glück eine halbe Nanosekunde für ein mittelprächtiges Auge. Kann man eine Senke so genau trimmen, dass sie das sicher tifft?
Heiko E. schrieb: > 40MB * 8 = 320 wären wohl das Mindeste. Also 160 MHz Clock und Daten mit DDR. Dann dreh den Takt hoch bis es Fehler gibt. Könnte/sollte klappen. > Es läuft wohl auf eine synchrone Übertragung mit Taktrekonstruktion auf > der Empfängerseite hinaus. Vermutlich besser aber auch schwieriger zu implementieren und braucht mehr Logik.
Moin, Heiko E. schrieb: > Angenommen, man lässt das auf 500MHz laufen, stehen gerade 2ns pro Takt > zur Verfügung. Das wäre mit gut Glück eine halbe Nanosekunde für ein > mittelprächtiges Auge. Kann man eine Senke so genau trimmen, dass sie > das sicher tifft? Bei der Software zur Xapp1064 gab's noch extra Brimborium, was sich selbstaendig auf die Mitte des Bits eingemessen hat und das auch im laufenden Betrieb nachgefuehrt hat. Ohne das Bits verschuett' gingen. Das "Kabel" sollte halt nicht zu popelig sein, oder du brauchst noch einen extra Cableequalizer. Gruss WK
Gustl B. schrieb: > Vermutlich besser aber auch schwieriger zu implementieren und braucht > mehr Logik. D.h. der eigentlich saubere Weg wäre, dem Serializer noch einen Takt mitzugeben, auf den er aufsetzen kann?
Heiko E. schrieb: > D.h. der eigentlich saubere Weg wäre, dem Serializer noch einen Takt > mitzugeben, auf den er aufsetzen kann? Nein. Wenn du single-ended machst, dann kannst du die beiden Leitungen getrennt benutzen. Dann würde ich ganz klar Daten + Takt wählen. Wenn du aber die beiden Leitungen differentiell verwenden willst (LVDS) dann würde ich ein Encoding verwenden, das die Taktrückgewinnung erlaubt. Letzteres ist aber eben schwieriger/komplexer, dann aber vermutlich die höhere Datenrate. Also was machen? Ich würde jetzt erstmal einen Takt, z. B. 250 MHz ausgeben, single-ended und gucken wie gut das Signal am Ziel ist. Wenn das noch halbwegs gut aussieht, dann kannst du mal Testdaten mit ausgeben und mit diesem Takt im Ziel-FPGA deserialisieren. Erstmal eine Folge mit einzelnen 1sen und auch einzelnen Nullen. Sowas wie 000001000011111011111 und dann siehst du ob im deserialisierten Datenstrom dann noch einzelne 1sen und Nullen auftauchen oder ob die fehlen oder gar doppelt nebeneinander auftauchen.
Takte doch deine Bits mit einen sync Leitung raus. Der Empfänger muss dann nur bei jedem sync Signal die Datenleitung wieder in ein Byte schieben. Du musst nur sicherstellen das du dem Empfänger genug Zeit gibst bis du das nächste Bit wieder raustaktest. Um welche Datenrate geht es überhaupt. Was für Daten willst du übertragen.
Es gibt ja beispielsweise FPD-Link iii - für Videoübertragung gedacht. Sowas z.B. https://www.ti.com/lit/ds/symlink/ds90ub921-q1.pdf Die Übertragung läuft entweder über STP oder Coax, mit irgendwas um die 3.5GBit/s. Plus: Du hast noch einen langsamen bidirektionalen Rückkanal für I2C oder so. Man muss ja nicht immer neue Räder erfinden. fchk
Heiko E. schrieb: > 50MB/s wären angestrebt. Klingt nach LVDS, das können manche FPGA schon von Haus aus.
Thomas O. schrieb: > Takte doch deine Bits mit einen sync Leitung raus. Das ist auch nichts anderes als Daten mit reduziertem Takt. Es werden jetzt 4 Leitungen. 2x LVDS für Daten und Takt. Spec steht. thx
Moin, He. schrieb: > Spec steht. Deshalb musste dich doch nicht gleich loeschen. Oder haengt's mit dem verlaengerten Urlaub zusammen? Axo, du kannst nicht mehr antworten - naja, dann blinzel halt mal... ;-) scnr, WK
He. schrieb: > Die beiden Baugruppen werden zwar aus dem gleichen Quarz > versorgt, aber das hat 25MHz. Da wird es nicht gelingen, eine feste > Taktkonstellation zu erzielen, Als Beispiel was mit den SERDES in einem Spartan 6 geht: Cameralink 30cm, mit 80MHz x 7/8Bit auf 560/640 Mbps, einmal Augen eingemessen und Eingänge gegen die PLL justiert. Passt dauerhaft ohne Nachjustieren. Takt und Daten kommen aber differenziell. Mit 25 MHz / single ended sehe ich da wenig Chancen. Mit 24.576 (S/PDIF) geht das in einen Artix mit Faktor 16. PLL im low jitter Modus und sehr stabiler OSC. Wahrscheinlich ist asynchron mit Taktrekonstruktion besser. Frank K. schrieb: > Es gibt ja beispielsweise FPD-Link iii - für Videoübertragung gedacht. Der Chip macht genau das. Ginge auch im FPGA, aber: > Die Übertragung läuft entweder über STP oder Coax, mit irgendwas um die > 3.5GBit/s. die SERDES packen das nicht. Was wäre denn mit Manchester? Ist zwar Bandbreitenverschwender, erlaubt aber eine sehr einfache Taktrekonstruktion.
Es gäbe z.B. Single Pair Ethernet, A2B oder wenn du es schnell haben möchtest und gleichzeitig noch eine galvanische Trennung, dann gehen z.B. auch VCSEL Dioden, wo du mit speziellen Chips Daten modulieren/demodulieren kannst.
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.