Hallo allerseits Ich soll für ein zukünftiges Projekt ein Variantenstudium durchführen, doch leider bin ich hier auf dem Gebiet der FPGA noch nicht so bewandert. Ziel ist es einen kontinuierlichen Datenstream vom PC auf das FPGA zu bringen, mit einer Datenrate von >=100 MBits/s. Die Daten sollen entweder in einem externen RAM oder im Block-Ram zwischengespeichert werden und werden für eine synchrone Puls-Generierung verwendet (Steuerung eines Lasers, dessen Hautp-Takt für das FPGA genutzt wird). Aktuell bin ich bei USB, Ethernet (hier denke ich über UDP/IP nach) und PCI(e) als mögliche Lösung angelangt. Jetzt stellt sich aber die Frage, der Realisierung. Und hier soll dabei eine möglichst einfache Lösung auf einem FPGA umgesetzt werden (wenn möglich in VHDL ohne zusätzlichen Soft-Core). Dafür können freie OpenCores eigesetzt werden, oder bei vernünftigem Verhältniss (Preis-Latenz) ein käufliches Produkt. Kann mir vielleicht jemand etwas "beratend" helfen? Besten Dank Patrick
Da fehlt die Angabe einer oberen Grenze. Bei bis zu 40 MByte/s d.h. 320 MBit ist das einfachste ein FT2232H USB 2.0 Controller zu verwenden.
Lattice User schrieb: > Da fehlt die Angabe einer oberen Grenze. Dies ist ja auch eine Mindestanforderung. Und ich weiss auch, dass hier eine 10G Ethernet-Verbindung zu teuer und zu komplex ist. Aber um die Sache zu ergänzen: 100MBit/s bis 800MBit/s (entweder werden die Daten Komprimiert oder normal gesendet, aber das muss ich noch abklähren) > Bei bis zu 40 MByte/s d.h. 320 MBit ist das einfachste > ein FT2232H USB 2.0 Controller zu verwenden. Gibt es da fertige Boards, auf denen ein FTDI-Chip drauf ist?
Ich kann aus eigener Erfahrung den Xillybus IPcore für PCIe empfehlen. Je nach FPGA sind 600MB/s möglich. Xillybus ist für Forschung kostenlos, und auf der FPGA Seite musst du nur ein FIFO passend verkabeln. Auf der PC Seite kannst du die Daten wie eine Datei lesen (named pipes). Für Forschung bekommt man auch passende FPGA Board umsonst. Ich habe beim DE4 von Altera umsonst bekommen. 300MB/s habe ich getestet. Wenn es für eine Firma ist kostet es zwar etwas, jedoch nicht viel.
Chris schrieb: > Ich kann aus eigener Erfahrung den Xillybus IPcore für PCIe empfehlen. > Je nach FPGA sind 600MB/s möglich. > Xillybus ist für Forschung kostenlos, und auf der FPGA Seite musst du > nur ein FIFO passend verkabeln. Klingt sehr Interessant, da das Projekt sowieso für die Forschung ist. Gibts da auch Windows-Treiber? Mhm, ich dachte, dass es bei FPGA einfacher ist, eine gute Kommunikation aufzubauen. Respektive dass man existierende Projekte verwenden kann. Nur ist das alles komplizierter als bei den Mikrocontrollern. Da gibts fertige Stacks und Beispielprojekte... aber bei den FPGAs herrscht hier irgenwie Flaute. Auch IP Cores finden sich nicht so wie Sand am Meer (obwohl FPGA ja sehr weit verbreitet eingesetzt werden).
Moin, mit dem guten alten FX2 von Cypress gibt es einige fertige Boards, z.B. von Digilent, oder das EFM01 von Cesys (Xilinx-Seite), oder das HDR60 (eher eine Kamera). Auf der FTDI-Seite gibts das Morph-IC Evalkit, da ist sogar ein Altera drauf, wenn du auf den Hersteller fixiert bist. Zu der Datenkommunikation gibts einige Threads, beim FT2232H muss man im Zusammenhang mit einigen älteren FPGAs etwas schauen, die Timings sind ab und an kritisch, da ist man mit dem FX2 besser bedient, aber nicht jeder will noch einen 8051 programmieren, zudem kommen da die USB VID/PID-Aspekte hinzu, die bei FTDI für Kleinserien entwicklerfreundlicher gehandhabt werden. Wo ich allerdings vielleicht den generellen Enthusiasmus etwas schmälern muss: viel gratis-IP bei OpenCores ist für industrielle Verwendung kaum brauchbar und man macht's im Endeffekt doch selber oder kauft den Core ein. Ich will ja nicht neugierig sein, aber geht das in Richtung LIDAR-style-Modulation, oder sogar ToF/VCSEL?
Strubi schrieb: > Ich will ja nicht neugierig sein, aber geht das in Richtung > LIDAR-style-Modulation, oder sogar ToF/VCSEL? Es soll eine 3d Oberflächengravur werden. Dabei muss ein bestehendes System etwas aufgebessert werden, weil die Geschwindigkeit zu langsam ist.
GBit Ethernet mit 1000 MBit ist schon machbar/vewendbar. Auch die Protokollschichten UDP/IP sind am sinnvollsten für die Anwendung. Aber die Implementation davon ist schon aufwendig und als ich letztes mal geguckt habe gab es keine kommerziellen IP Cores die man für normales Geld kaufen konnte. Alles was von Xilinx kommt TriMac- Core und S/Gmii-Interface und so weiter das ist in 2 Wochen selbst entwickelt aber hat nichts mit UDP/IP Protokoll zu tun sondern ist 2 Protokollebenen drunter, d.h. den Rest müsste man trotzdem selbst entwickeln. Falls du wirklich viele Ahnung von Windows/Betriebssytem/Treiberentwicklung hast, kannst du auch dein eigenes Protokoll ganz hardwarenah entwerfen und verwenden, damit kann man natürlich auch den Aufwand der FPGA-Implementation dratisch verringern. Andere Möglichkeit wäre die Verwendung eines Softcore und eines Opensource-Stacks (LwIP, Uip) aber auch das ist denke ich aufwendig. Ich kenne mich mit Softcores aber auch nicht aus. Den UIP-Stack kenne ich etwas. Der ist relativ resourcenschonend aber verschiedene Test haben ergeben, das er auch nicht wirklich viel Performance bringt. Ich hab mal ein Paper gefunden, da wurde in Tests gerade mal 20-30 % der maximalen Datenrate bei 100 Mbit Ethernet erreicht. Zu USB: ein Kollege von mir hat mit dem FX3 und nem Spartan gearbeitet und USB 3.0 implementiert. War ne Menge Arbeit und funktioniert auch nicht problemlos und weit weg von der maximalen Datenrate... trotz vieler vorgefertigter Module von Cypress. Weder Ethernet noch USB ist wirklich einfach zu verwenden mit FPGA. Das braucht schon Arbeit die ganzen Protokollschichten zu implementieren.
Trundle Trollkönig schrieb: > Zu USB: ein Kollege von mir hat mit dem FX3 und nem Spartan gearbeitet > und USB 3.0 implementiert. War ne Menge Arbeit und funktioniert auch > nicht problemlos und weit weg von der maximalen Datenrate... trotz > vieler vorgefertigter Module von Cypress. Kann ich nicht ganz nachvollziehen. Wir setzen den FX3 auch ein. Klar, bissl Einarbeitung ist schon nötig, aber das Sync Slave FIFO Beispiel kann man quasi direkt verwenden. Auf FPGA Seite dann eine kleine State Machine und los gehts. Die Datenrate erreicht man allerdings nur mit großem Puffer. Die 100MHz PCLK hab ich allerdings selbst mit dem Artix nicht hinbekommen. Ich arbeite momentan mit 80MHz/32 Bit und bekomme je nach Host Controller bis zu 300MB/s in den PC rein und knapp 200MB/s vom PC zum FPGA. Da fehlen einfach die großen Puffer auf der Host Seite.
Trundle Trollkönig schrieb: > Weder Ethernet noch USB ist wirklich einfach zu verwenden mit FPGA. Das > braucht schon Arbeit die ganzen Protokollschichten zu implementieren. Die Kunst bei Ethernet sich auf das wesentliche zu beschränken. 1.) Einen Trimac braucht es nicht. GMII oder RGMII reicht völlig. 2.) Einen Phy verwenden der selbständig, d.h, ohne Konfiguration den Link aufbaut. 3.) Es wirklich als Punkt zu Punkt zu betreiben, d.h. auf der PC Seite eine eigene Netzwerkkarte. 4.) Nur Ethernet Raw Packets verwenden, kein ARP,IP etc. 5.) Erstmal nur die Richtung PC->FPGA mit fester Packetlänge implementieren. Unter diesen Bedingungen ist es für jemanden mit Erfahrung nur ein paar Stunden bis man Daten in einen Blockram oder Fifo empfangen kann.
Christian R. schrieb: > Kann ich nicht ganz nachvollziehen. Wir setzen den FX3 auch ein. Klar, > bissl Einarbeitung ist schon nötig, aber das Sync Slave FIFO Beispiel > kann man quasi direkt verwenden. Auf FPGA Seite dann eine kleine State > Machine und los gehts. Die Datenrate erreicht man allerdings nur mit > großem Puffer. Die 100MHz PCLK hab ich allerdings selbst mit dem Artix > nicht hinbekommen. Ich arbeite momentan mit 80MHz/32 Bit und bekomme je > nach Host Controller bis zu 300MB/s in den PC rein und knapp 200MB/s vom > PC zum FPGA. Da fehlen einfach die großen Puffer auf der Host Seite. Soweit ich das mitbekommen habe, hast du aber eine Menge Erfahrung mit FPGAs. Der TO meinte er wäre nicht wirklich bewandert... keine Ahnung wie was das genau bedeutet. Mein Kollege hat schon Erfahrung mit FPGAs mehr noch CPLDs aber sicher nicht dein Level. Insgesamt mit Windowstreiber-Entwicklung FX3 Einarbeitung /Konfiguration und FPGAs-Module anpassen, etc, waren das mindestens 3-6 Mannmonate bis es einigermaßen gut funktioniert hat. Ok der hat auch noch andere Sachen erledigt. Wie auch immer, wenn man kein Pro ist denke ich wird man schon ein paar monate brauchen. > 4.) Nur Ethernet Raw Packets verwenden, kein ARP,IP etc. unsere Softwareabteilung meinte dafür muss man nen eigenen Treiber schreiben... zumindest unter Windows... aber davon hab ich nicht wirklich Ahnung und wieviel Zeit es beansprucht weiß ich auch nicht. Aber richtig ist mit Raw-Pakets kann man auf den ganzen Protokollkrams verzichten und das ist natürlich viel einfacher.
Trundle Trollkönig schrieb: > >> 4.) Nur Ethernet Raw Packets verwenden, kein ARP,IP etc. > > unsere Softwareabteilung meinte dafür muss man nen eigenen Treiber > schreiben... zumindest unter Windows... aber davon hab ich nicht > wirklich Ahnung und wieviel Zeit es beansprucht weiß ich auch nicht. > Aber richtig ist mit Raw-Pakets kann man auf den ganzen Protokollkrams > verzichten und das ist natürlich viel einfacher. http://www.winpcap.org/ Wird u.A. auch vom WireShark benuztzt. Den braicht man ohnehin zum Debuggen.
Ertmals besten Dank für die sehr ausführlichen Antworten. Leider stimmt mich das wenig optimistisch. Ich muss mich demnach mal mit unseren FPGA-Guru zusammenstzen. Bezüglich Ethernet gibt mir die Spezifikation "unsicher" etwas zu denken: Anscheinenden werden auf den unteren Ebenen 10^(-10) fehlerhafte Datenpakete zugelassen... Das würde mich wieder zu PCI bringen. Aber wie gesagt, werde das mal mit einem Kollegen besprechen. Trundle Trollkönig schrieb: > Der TO meinte er wäre nicht wirklich bewandert... keine Ahnung > wie was das genau bedeutet. Soll heissen, dass ich erst etwa 4 Projekte auf einem FPGA umgesetzt habe, und die waren nicht wirklich schwierig.
Patrick B. schrieb: > Ziel ist es einen kontinuierlichen Datenstream vom PC auf das FPGA zu > bringen, mit einer Datenrate von >=100 MBits/s. USB 3.0. Ethernet ist erheblich aufwändiger und bei einer Leitung (800 Mbsps) kaum möglich.
Von Xilinx und Altera gibt es auch SoCs: also Arm-CPU mit integriertem FPGA. Die Kommunikation dann einfach über die CPU und Ethernet ablaufen lassen, und den FPGA-Teil für die Hardware-Bedienung.
> Kann ich nicht ganz nachvollziehen. Wir setzen den FX3 auch ein. Klar, > bissl Einarbeitung ist schon nötig, aber das Sync Slave FIFO Beispiel > kann man quasi direkt verwenden. Auf FPGA Seite dann eine kleine State > Machine und los gehts. Die Datenrate erreicht man allerdings nur mit > großem Puffer. Die 100MHz PCLK hab ich allerdings selbst mit dem Artix > nicht hinbekommen. Ich arbeite momentan mit 80MHz/32 Bit und bekomme je > nach Host Controller bis zu 300MB/s in den PC rein und knapp 200MB/s vom > PC zum FPGA. Da fehlen einfach die großen Puffer auf der Host Seite. Hi Christian, bei mir läuft PCLK mit 102 MHz auf einem Spartan6 -2 (Bulk IN-EP). Der Trick dabei ist nur, die 16k (FX3 Buffer) im FPGA selber mit zu zählen. Somit kann man diese lästigen Flags ignorieren und selber schnell genug anhalten. Alle Signale für das GPIF in IOBs packen und fertig. Macht mit Intel Karte 376MB/s. Schwieriger wird es natürlich, wenn der Datenstrom nicht kontinuierlich ist. Aber auch da gibt es ein paar Tricks ;) Gruß Marco
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.