Forum: FPGA, VHDL & Co. USB-Verbindung zwischen zwei FPGAs


von OnkelDok (Gast)


Lesenswert?

Hey, hat jemand Erfahrung mit einer Kommunikation zwischen zwei FPGAs 
mittels USB?
Die beiden FPGAs sitzen dabei auf unterschiedlichen Platinen (deshalb 
die USB-Schnittstelle).

Ein Austausch von Daten zwischen PC und FPGA ist ja z.B. mit dem FT2232 
von FTDI möglich. Wenn ich mich richtig informiert habe, klappt der 
Datenaustausch jedoch nur zwischen FPGA und PC, weil mit der vorhandenen 
API der Chip entsprechend konfiguriert wird.
Dabei hätte man ja folgende Datenflüsse:
PC(API) <--(USB)--> FT2232 <--(SPI/FIFO)--> FPGA.

Bei einer USB-gestützen Kommunikation zwischen zwei FPGAs hätte ich mir 
das jetzt so vorgestellt:
FPGA1 <--(SPI/FIFO)--> FT2232 <--(USB)--> FT2232 <--(SPI/FIFO)--> FPGA2

Ich vermute mal, dass dies jedoch nicht möglich ist (wenn doch, dann 
belehrt mich eines Besseren). Gibt es entsprechend andere ICs, die für 
diese Anwendung möglich wären (ohne dass für den/im IC großartig 
Programmcode erstellt werden muss)?
Oder sollte ein komplett anderer Ansatz gesucht werden?

Grüße

von Strubi (Gast)


Lesenswert?

Hi OnkelDok,

muss Dich enttäuschen, das geht leider so überhaupt nicht.
Der FT2232 kann erstens nicht "Host"-Betrieb, d.h. die A-Seite des 
USB-Kabels kriegst du da nie ran. Es gäbe da allerdings die 
Vinculum-Serie, die kann Host.

Nichtsdestotrotz ist eine solche Kommunikation jedoch hochkomplex, ohne 
Soft-Core (kleine mit eingebackene CPU) kannst Du das gleich vergessen.
Besonders auf der Host-Seite ist das USB-Handling hochkomplex.

Ich würde die Sache möglichst einfach halten und die Geschichte per LVDS 
realisieren. Bei Spartan6 wäre der PCIe ev. ne Variante, da gehen sogar 
recht lange Verbindungen (locker 20 cm). Nur ne Frage der Kabel..


Grüsse,

- Strubi

von Wolfgang R. (portside)


Lesenswert?

USB braucht Master und Slave. Ob ein FT2232 als Master konfiguriert 
werden kann?? Wohl kaum.
USB funktioniert so was es kostet nämlich nicht. Hobby Elektonik.
Nicht umsonst generiert Apple Thunderboldt als Gegenstück zu USB3.
Nimm Firewire das sind alle Seiten Master oder Slave.
Wenn die Daten nicht zu schnell sind ist CAN eventuell eine Lösung.

von user (Gast)


Lesenswert?

wenn es richtig lang sein soll, kannst du ein RS422 Treiber nehmen

von user (Gast)


Lesenswert?

Oder Ethernet

von Gustl B. (-gb-)


Lesenswert?

Ich würde zwischen zwei FPGAs etwas möglichst einfaches verwenden, das 
zu deinem Anwendungsgebiet passt. Interessant wäre natürlich auch die 
Entfernung, die überbrückt werden muss. USB oder FW würde ich eigentlich 
nicht nehmen, für kurze Entfernungen kannst du ja einfach Pins der 
beiden FPGAs verbinden und schon hast du eine Verbindung über die du 
genau so wie du es willst Daten übertragen kannst. Vielleicht parallel 
über mehrere Drähte gleichzeitig oder mit hohem Takt seriell, oder auch 
langsam seriell, mit zwei einfachen verbindungen bekommst du schon eine 
RS232 hin und kannst die natürlich so hoch takten, wie es die Leitungen 
zulassen.

Ist eben die Frage welche Datenrate du wie weit übertragen willst.

-gb-

von OnkelDok (Gast)


Lesenswert?

Alles klar, erstmal vielen Dank für die Antworten.
Ich hab natürlich vergessen die Eckdaten zu beziffern. Die 
Geschwindigkeit sollte im Minimum 12 Mbit/s betragen und die Entfernung 
zwischen den beiden FPGA-Platinen beträgt 5m oder mehr. Zwecks 
Kabellänge gibts ja die "Active Extension Cables".

Von der Funktion her ist der eine FPGA der Controller und soll Daten 
über eben diese USB-Verbindung an den zweiten FPGA schicken. Ein 
Rücklauf dieser Daten zum ersten FPGA ist (vorerst) nicht vorgesehen. 
(Obwohl: wenn ich mir das richtig überlege, dann ähnelt der 
datensendende FPGA ja einem Device (ähnlich einer Maus/Tatstur), der 
einfach nur Daten schickt.)

Die beiden USB-SPI-Umsetzer müssten theoretisch die Daten einfach 
weiterschleifen, ohne diese großartig auszuwerten.

Die Vinculum-Reihe hab ich mir auch angeschaut - Vinculum II bietet ja 
SPI-Master- &Slave-Interace. Und mit dem "Toolchain" könnte man Firmware 
entwickeln und aufbringen. Wie kompliziert das ist, kann ich aber leider 
nicht einschätzen.

Es gibt auch noch den MAX3421E 
(http://www.maximintegrated.com/datasheet/index.mvp/id/3639)
Hat jemand damit mal gearbeitet?


Grüße

PS: Tut mit Leid, wenn ich auf Vorschläge für andere 
Übertragungsmöglichkeiten noch nicht eingehe. Ich möcht erstmal alles 
für eine USB-Übertragung durchspinnen. :)

von DuArte (Gast)


Lesenswert?

>Obwohl: wenn ich mir das richtig überlege, dann ähnelt der
>datensendende FPGA ja einem Device (ähnlich einer Maus/Tatstur), der
>einfach nur Daten schickt.)

Das stimmt nicht! USB-Kommunikation ist IMMER in beiden Richtungen, egal 
in welcher Richtung dann tatsächlich die "Nutzdaten" geschickt werden.

von Gustl B. (-gb-)


Lesenswert?

Naja, USB ist halt doch eine Herausforderung das da einzubauen, ich 
würde vermuten, dass du 12MBits auch über ein geschirmtes Coaxkabel 
bekommst - wenn du sowieso nur eine Richtung brauchst. Aber musst du 
wissen, ich halte USB für diese Anwendung viel zu aufwändig, frisst ja 
auch Platz in den FPGAs, braucht zusätzliche Chips vermutlich ... und 
ist eben nicht einfach.

-gb-

von P. K. (pek)


Lesenswert?

OnkelDok schrieb:
> PS: Tut mit Leid, wenn ich auf Vorschläge für andere
> Übertragungsmöglichkeiten noch nicht eingehe. Ich möcht erstmal alles
> für eine USB-Übertragung durchspinnen. :)

LVDS und CAT3 (ev CAT5) Twisted pair wäre meine erste Stossrichtung. Für 
so eine Anwendung reicht ein proprietäres Modell ohne den ganzen Aufwand 
ein Standardprotokoll zu supporten. Und das Kabel musst Du ja trotzdem 
nicht selber konfektionieren, gibt's ja ab Stange.

von Strubi (Gast)


Lesenswert?

Jemand hat's schon quasi gesagt, dass USB eigentlich "broken by design" 
ist. Für eine zuverlässig/wirtschaftliche Lösung würde ich ehrlich 
gesagt, die Finger von USB lassen. Habe nun schon mit diversen Chips 
rumgewurschtelt (allerdings nicht mit obigem Maxim), man muss ne Unmenge 
FIFOs und Intelligenz spendieren (d.h. Firmware schreiben) um 
USB-Transfers mit allen Bedingungen vernünftig abzuhandeln. Die 
Slave-Seite ist nicht so die Wahnsinns-Hexerei, aber auch da gabs schon 
genügend Tretminen, und es ist alles recht mühsam zu debuggen, besonders 
auf der Hardware.
Firmware zu schreiben ist aber bei der Sache das geringste Übel, solange 
man sie debuggen kann.
Abgesehen davon: Man kann auch einfach das USB-Kabel mit einem simplen 
Phy für sein eigenes Protokoll missbrauchen..

von OnkelDok (Gast)


Lesenswert?

Hm...und fertige Adapter (boards/Platinen), die von USB auf ein 
Standardinterface (und zurück) "umstellen" gibt's nicht?

Dann werd ich wohl doch eher die Finger von USB lassen und meine Fühler 
in Richtung LVDS ausstrecken müssen.

von Christian R. (supachris)


Lesenswert?

Mach das. USB ist für diesen Anwendungszweck wirklich komplett daneben. 
12 MBit/s erreichst du locker über RS485 für einige Meter oder halt mit 
4 Koax-Leitungen wenn es Dual-Simplex LVDS sein soll.

von Mark W. (kram) Benutzerseite


Lesenswert?

Hallo,

ich denke auch, ethernet waere hier am geeignetsten.
12 Mbit/s und 5m sind da locker drin.

Wenn es die bosrds aber schon gibt und die schon den USB chip drauf 
haben,
dann vielleicht mal schauen, ob der OTG kann. Denn dafuer ist es wohl 
gedacht.

An sonsten ethernet realisieren oder wenn es denn USB sein muss, einen 
chip nehmen, der OTG kann. Dann kann eines der beiden boards auch nur 
device bleiben.

Mark

von Christian R. (supachris)


Lesenswert?

Ohja, Ethernet ist ja immer das einfachste mit einem FPGA ;)
Mal im Ernst, durch den Protokoll-Overhead wäre rein mit dem FPGA nur 
UDP drin, TCP ist ohne Softcore nicht wirklich machbar. Mit USB OTG 
wirds da nicht viel einfacher. Rein um nur 2 FPGA Boards zu verbinden 
gibts tausend andere Möglichkeiten, die allesamt einfacher, 
zuverlässiger und besser passend für diesen Zweck sind.

von user (Gast)


Lesenswert?

Ja, bei ethernet kannst du ja auch nur den physical layer verwenden

von D. I. (Gast)


Lesenswert?

Raw Ethernet ist nun wirklich keine Rocket Science

von Christian R. (supachris)


Lesenswert?

Ja, RAW Ethernet oder auch UDP noch, das geht schon. Aber wieso sollte 
man es sich so kompliziert machen? Eine einfache (LVDS) Verbindung mit 
selbst erdachtem Protokoll ist da 10 mal einfacher implementiert und 
erfordert keinen extra PHY. Aber wir kennen ja die Anforderungen nicht, 
die werden ja gerne verschwiegen hier.

von Lattice User (Gast)


Lesenswert?

Christian R. schrieb:
> Ja, RAW Ethernet oder auch UDP noch, das geht schon. Aber wieso sollte
> man es sich so kompliziert machen? Eine einfache (LVDS) Verbindung mit
> selbst erdachtem Protokoll ist da 10 mal einfacher implementiert und
> erfordert keinen extra PHY. Aber wir kennen ja die Anforderungen nicht,
> die werden ja gerne verschwiegen hier.

"gast" meint weniger als RAW Ethernet, nur den Physical layer.
Und das ist sehr einfach wenn man einen Phy hat, der sich per Pins oder 
EEProm fix konfigurieren lässt.
Vorteil: Billige Kabel, bis zu 1 GBit/s, bis zu 100m, galvanisch 
getrennt, unproblematisch.

Die Anforderungen des TE sind übrigens teilweise genannt, bis zu 10 
MBit/s, > 5m. Was fehlt ist eine maximal Distanz.
10 MBit/s über 5m ist nicht viel, aber IMO schon im Bereich wo man über 
AC Kopplung nachdenken sollte.

von Christian R. (supachris)


Lesenswert?

OK, wenn man das soweit abspeckt, ist es sicher auch eine Idee.

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.