Forum: FPGA, VHDL & Co. Datenübertragung über nur 2 Leitungen


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 He. (Gast)


Lesenswert?

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.

von Gustl B. (gustl_b)


Lesenswert?

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.

von He. (Gast)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von He. (Gast)


Lesenswert?

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?

von Gustl B. (gustl_b)


Lesenswert?

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.

von Dergute W. (derguteweka)


Lesenswert?

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

von He. (Gast)


Lesenswert?

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?

von Gustl B. (-gb-)


Lesenswert?

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.

von Thomas (kosmos)


Lesenswert?

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.

von Frank K. (fchk)


Lesenswert?

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

von Michael B. (laberkopp)


Lesenswert?

Heiko E. schrieb:
> 50MB/s wären angestrebt.

Klingt nach LVDS, das können manche FPGA schon von Haus aus.

von He. (Gast)


Lesenswert?

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

von Dergute W. (derguteweka)


Lesenswert?

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

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

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.

von PCB (pcbee)


Lesenswert?

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.

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.