Hallo allerseits Habe eine Frage bezüglich USB Device Controller Chips. Ich würde gerne einen FPGA über USB ansprechen, also im Grunde Daten hin- und herübertragen. An JTAG über USB bin ich proformer erstmal nicht interessiert. Ich habe bisher nur diesen FTDI 2232x gefunden, den man verschiedenes konfigurieren kann und diesen oft erwähnten Chip: Cypress FX2... Beide im Detail doch komplex und vorallem der FTDI-Chip doch sehr dürftig dokumentiert... und beide benötigen spezielle Windows-Treiber.. Daher meine beiden Fragen: 1. Ich würde gerne wissen ob es einen simplen Chip gibt mit dem man die volle High-Speed USB Übertragungsrate erreichen kann (zb. als paralleler Anschluß an den FPGA oder gibt es da sogar ne bessere Art ihn anzuschließen ?)? 2. Gibt es auch einen Chip der ohne große Treiberinstallation über den USB Host erkannt werden kann (zb. wie bei USB Mass Storage Devices) oder ist bei einer solchen Verwendung eines USB-Geräts eine Treiberinstallation unabingbar? Danke schonmal für die Hilfe lg arcticus
1. Also die beiden Kandidaten hast du schon genannt. FT2232*H* und Cypress FX2. Beide können USb 2.0 HighSpeed und sind relativ leicht beschaffbar und konfigurierbar. Der FTDI hat den Vorteil, dass du keine Firmware für den Controller schreiben musst. Der schafft allerdings nur etwa so 25MB/s laut Datenblatt. Der Cypress ist ein 8051 µC mit USB Hardware dran. Da muss man eine Firmware laden und dann macht der fast alles alleine. Die Firmware sind im Prinzip nur Register-Einstellungen. Ist etwas komplexer, aber damit erreicht man echte 40MB/s. Mehr geht nicht mit HighSpeed. 2. Das wird schwierig. Du kannst den FX2 als MSD programmieren, da gibts auch eine Beispiel-Firmware von Cypress, dann verlangt der keinen Treiber. Ist dann allerdings ein ATA-Controller mit ATA Interface. Da musst du im FPGA einen ATA Slave implementieren und den aus Windows heraus als BlockDevice oder ganz unten über die IO Controls des Treibers ansprechen. Dazu brauchst du allerdings Admin-Rechte. Ob das so sinnvoll ist? Für den Cypress hast du nur eine einzige Treiber-Datei, gibts auch als x64 mittlerweile. Wir setzen den erfolgreich ein, privat hab ich auch damit gebastelt. Eine Beispiel-Firmware von mir findest du im Forum hier.
Hallo, ob ein hostseitiger USB-Gerätetreiber geschrieben/bereitgestellt werden muss, hängt vor allem von der zu unterstützenden Geräteklasse ab. Für HID (Human Input Device wie Maus, Tastatur, Joystick), Mass Storage und einige Varianten von CDC (Communication Device Class) kann man die Standardtreiber des Betriebssystems verwenden. Jedoch ist bei älteren Windows-Versionen die Host-Implementierung des CDC ACM so schlecht, dass die meisten Hersteller von USB-/Seriell-Wandlern lieber auf eigene Implementierungen eines USB-basierten Protokolls setzen (FTDI, Prolific, Moschip, usw.). Wenn man ein FPGA verwendet, bietet sich - je nach Anwendung - die Verwendung eines internen USB-Blocks an, je nach FPGA mit oder ohne externen reinen USB PHY. Jedoch benötigt man im Allgemeinen noch einen Prozessorkern für das "High Level"-Protokoll, z.B. einen Picoblaze oder 8051-/Z80-Softcore. Auf Opencores befindet sich ein aktiv gepflegter USB-Block für Host und Function, jedoch nur für USB 1.1: http://opencores.org/project,usbhostslave Mit einem USB-/Seriell-Wandler wird man nicht ansatzweise auf eine für Nutzdatenrate von >10MBit/s kommen. Geht es bei dem Projekt um eine private Bastelei oder ein kommerzielle Produktentwicklung? Gruß Andreas Schweigstill
Ne es geht um meine Diplomarbeit ;) Grob geht es um eine externe FPGA Lösung, die man auch mal irgendwo hin mitnehmen kann, um "Kunden" etwas zu demonstrieren, wozu zb. ein PCIe Interface net so gut kommt -> ala "Machen se doch mal den Rechner auf" ... daher wäre natürlich eine Lösung vorteilhaft, in der nicht zuviel an Zusatztreibern installiert wird... --------- Beispiel-Firmware von Cypress, dann verlangt der keinen Treiber. Ist dann allerdings ein ATA-Controller mit ATA Interface. Da musst du im FPGA einen ATA Slave implementieren und den aus Windows heraus als BlockDevice oder ganz unten über die IO Controls des Treibers ansprechen. Dazu brauchst du allerdings Admin-Rechte. --------- Also nehm ich mal an eine Lösung ohne Treiberinstallation zielt primär nur auf MSD ab (ich nehme mal an als HID wird das erst recht nicht klappen) mit den oben genannten Einschränkungen... Ganz allgemein stehen im Raum halt: 1) USB 2.0; 40 MB/s max. Performance mit den oben genannten Chips 2) Gigabit-Ethernet; 80 MB/s ungefähr mit TCP, kann auch mit einem Chip vor dem PFGA implementiert werden...ist eher Cluster-fähig Das steht so ungefähr zur Debatte und die Frage bleibt, was wäre für den obigen Kundenbesuch quasi eher von Vorteil... ich glaube Ethernet könnte da Treiberseitig besser sein ;) lg arcticus
Eine GbE Implementierung in Hardware incl. Protokollstack auf einem MicroBlaze oder PowerPC da im FPGA ist in einer Diplomarbeit nicht zu schaffen. Das ist ein enormer Aufwand und für "mal schnell beim Kunden zeigen" überhaupt nicht geeignet. Der muss dann erst sein Firmennetz abklemmen, IP eventuell umstellen, ein Cross-Kabel anschließen. Das ist viel mehr Aufwand als einen Treiber zu installieren. HID und CDC ist schnarchlangsam, das bringt dich nicht weiter. MSD ist wieder nicht dafür gedacht. Da es eine Diplomarbeit ist, würde ich den FT2232H empfehlen. Alleine aus Zeitgründen.
Ich bin nicht allein und würde das GbE auch nicht selbst im FPGA implementieren wollen sondern eher nen Chip davorsetzen mit Phy und MAC, der nurnoch die Daten weiterleitet, aber das andere Argument ist auch gut... Also würdest du sagen man könnte eher nen Treiber installieren als nen Gerät per Ethernet anschließen ?
Hallo! Christian R. schrieb: > Eine GbE Implementierung in Hardware incl. Protokollstack auf einem > MicroBlaze oder PowerPC da im FPGA ist in einer Diplomarbeit nicht zu > schaffen. Das ist ein enormer Aufwand und für "mal schnell beim Kunden > zeigen" überhaupt nicht geeignet. Exakt. Eine gewisse Restchance bestünde noch, wenn man auf eine fertige Referenzimplementierung zugreifen kann. Vermutlich wird dann aber das FPGA schon so voll sein, dass kaum noch Platz für das eigene IP frei ist. > Der muss dann erst sein Firmennetz > abklemmen, IP eventuell umstellen, ein Cross-Kabel anschließen. Das ist > viel mehr Aufwand als einen Treiber zu installieren. Vor allem wird es so mancher Kunde (oder die Sicherheitsrichtlinien des Unternehmens) nicht mögen, dass Dritte einfach so Netzwerkkomponenten mitbringen und in ihrem Netz anklemmen wollen. Man kann ja nicht ohne weiteres erkennen, ob es sich dabei nicht um einen "Hardware-Trojaner" handelt, dessen eigentlicher Zweck darin besteht, einen Netzwerkscan durchzuführen und ggf. Daten abzusaugen. Bei einem mitgebrachten Gerätetreiber oder Anwendungsprogramm besteht diese Gefahr natürlich auch, genauer: sie ist noch deutlich höher. > HID und CDC ist schnarchlangsam, das bringt dich nicht weiter. MSD ist > wieder nicht dafür gedacht. Oh, auf MSD-Basis kann man sehr schöne Dinge machen, z.B. das Installationsmedium für Treiber und Anwendung mitbringen, so wie es heutzutage viele UMTS-Schniepel machen. Ich habe auch schon Anwendungen gesehen, bei denen die Nutzdaten einer Erfassungseinrichtung als virtuelle Speicherblöcke eines MSD abgelegt wurden. Bei SAN-Komponenten (Storage Area Network) ist es häufig auch so, dass die Steuer- und Konfigurationsdaten nicht über einen zeichenbasierten Kanal oder entsprechende SCSI-/Fiberchannel-Befehle übertragen werden, sondern über ein kleines blockbasiertes Speichergerät. Kommandos werden dadurch abgesetzt, dass sie in bestimmte "Sektoren" dieses Geräts geschrieben werden. Hierbei werden keine Dateien angelegt! http://www.tek-tips.com/viewthread.cfm?qid=756438&page=20 Einen dateibasierten Ansatz kann man aber auch gelegentlich finden, d.h. auf der Host und das Gerät greifen gemeinsam z.B. auf ein FAT-Dateisystem zu, das sich in einer Ramdisk des Geräts befindet. Für Kommandos oder schnelle Datentransfers ist dies aber nicht geeignet, sondern eher für die Übertragung von Konfigurationsdateien. Im Linux-Kernel befindet sich hierfür die sog. "USB Gadget"- Unterstützung, bei der man ein virtuelles MSD (neben CDC (ACM, "Ethernet"), Remote NDIS, usw.) realisieren kann. Apropos RNDIS: Dies wäre natürlich auch noch eine Möglichkeit. Es handelt sich dabei um ein Paar virtueller Netzwerkkarten, von denen eine auf dem PC sichtbar wird. Darauf aufsetzend kann man dann TCP/IP benutzen. Der Entwicklungsaufwand ist aber nur dann erträglich, wenn man schon auf einem geräteseitigen Linux-System aufsetzen kann. > Da es eine Diplomarbeit ist, würde ich den FT2232H empfehlen. Alleine > aus Zeitgründen. Ich kenne den Baustein zwar noch nicht, aber das dürfte vermutlich der Weg mit dem erträglichsten Entwicklungsrisiko sein. Gruß Andreas Schweigstill
Hallo! Marcel C. schrieb: > Ich bin nicht allein und würde das GbE auch nicht selbst im FPGA > implementieren wollen sondern eher nen Chip davorsetzen mit Phy und MAC, > der nurnoch die Daten weiterleitet, Und wer konfiguriert den Ethernet-Chip und stellt das Übertragungsprotokoll bereit? Für eine kleine FSM im FPGA dürfte das etwas zu heftig werden, so dass es dann schon auf einen Softcore hinausliefe. Und wenn man einen solchen verwenden will, bietet es sich eher an, das Ethenet-MAC gleich mit ins FPGA zu packen statt eine PCI- oder PCIe-Schnittstelle zum externen Ethernet-Baustein vorzusehen. Gruß Andreas Schweigstill
Ja, über MSD kann man sowas abfackeln. Aber wenn man kein virtuelles Datei-System benutzt, muss man zwingend Admin sein, um Blockweise zugreifen zu können. Die Idee wollten wir auch schon mal umsetzen, aber haben es dann zugunsten des Cypress FX2 fallen lassen. Nochmal zu GbE: Schlag dir das aus dem Kopf. An sich eine feine Sache, aber der Aufwand für eine gesicherte, zuverlässige Datenübertragung (incl. aller nötigen Protokolle) ist einfach für den bearbeitungszeitraum zu hoch. Wir haben das mal angefangen, mit dem ML405 Board, auch als Diplomarbeit. Zum Glück hatte der Diplomand schon 10 Jahre Programmier-Erfahrung, da hat er zumindest am Ende der DA eine halbwegs stabile Datenübertragung aus dem SDRAM zum PC hinbekommen. Allerdings nut UDP, feste IP usw. Der mitgelieferte LW IP-Stack ist ein guter Einstiegspunkt, allerdings nicht performant genug. Die Einarbeitung in die MAC-Funktionalität, den PowerPC, den DMA Controller usw. ist einfach zu lang für eine DA. Außerdem war selbst der Virtex 4 FX20 dann fast voll mit MAC, PPC, DMA und ordentlichen Puffern für den MAC, damit die Datenübertragung auch schnell geht. Vom Preis mal ganz zu schweigen. Ich rate dir dringend zum FTDI oder Cypress, damit kommst du am schnellsten zum Ziel. Kannst ja den Cypress nehmen, zunächst mit der normalen Firmware, die den cyUSB Treiber benutzt, und wenn noch zeit ist, oder nach der DA das auf die MSD Variante umbauen.
Ich kenn mich mit Netzwerk nicht so genau aus, mein DA Partner aber schon... aber da die Diplomarbeit nicht nur daraus besteht diesen Chip zu implementieren würde ich schon die simpelste Alternative wählen wollen ;) Aber noch kurz zu Ethernet: Also die Idee ist eine externe Lösung, d.h. quasi ein Board mit RJ45 -> GbE-Chip -> FPGA, also nicht über PCI oder Ähnliches, und es gibt keinen Chip der das TCP Protokoll unterstützt, die Daten auseinanderschnürt/zusammenschnürt und einfach zum FPGA und zum am Ethernet-Kabel angeschlossenen PC schickt, ohne groß im FPGA rumzuprogrammieren ? Z.B. (mal ganz weg von dem Kundengedanken) um mehrere FPGA-Karten über Netzwerk zu clustern... --- Zum USB-Chip: 1. Wie schaut denn bei den bei den Chips (FTDI, Cypress) die Verbindung zwischen Chip und FPGA aus um eine max. Bandbreite zu erzielen, einfach parallele Leitungen?... im FTDI-Guide steht was von "FT245-style syncr. FIFO interface", was soll das bitte sein ? 2. Wie schauts mit vorgefertigten Programmierung für den Cypress-Chip aus, gibts da vll schon nen Code für Datenübertragung mit max. Bandbreite zu finden ? 3. Bei dem FTDI-Chip ist ja scheinbar nen EEPROM notwendig, um die Konfiguration zu speichern, sind beim Cypress-Chip auch irgendwelche externen Bauteile nötig (außer den Offensichtlichen) ? 4. Wie schauts mit der Syncronisierung der Clock aus zwischen Chip und FPGA, ich nehme mal an In und Output sollten beide mit der selben Frequenz getaktet werden? Danke euch beiden schonmal, wart ne große Hilfe bisher ;) lg marcel
Mit FT2232H, eigenen FPGA Code und abgewandelten fastftdi.c svn.navi.cx/misc/trunk/nds/dsi/ram.../fastftdi.c Code habe ich 28 MByte/sec erreicht. Ansonsten sind das FTDI Datenblatt und die App-Notes Dein Freund.
Nochmal zu deinem "GbE-Chip": Den gibts leider nicht. Mir ist kein derartiger Chiop bekannt. Sowas wie WizNet für GbE hab ich nirgends gefunden. Zur Verbindung des FX2 zum FPGA: Am besten alle Leitungen anschließen, dann kannst du sychrones Slave-FIFO Interface machen. Das bringt den maximalen Durchsatz. Takt kannst du aus dem FX2 bereitstellen oder extern vom FPGA, kann man umschalten. Die Firmware kannst du aus einem externen EEPROM laden (das gescheiht automatisch), oder bei jedem Anstecken über USB reinladen lassen, geht auch automatisch, wenns einmal im Inf-File des Treibers drin is. Ein kleiner externer EEPROM am FX2 ist dann trotzdem erforderlich, um die Vender/Device ID zu speichern. Beispielcode für synchrones Slave-FIFO Interface gibts hier von mir getestet: Beitrag "Re: USB-Port auf Spartan 3E für Anwendung nutzen" das erreicht 40MB/s bei 16 Bit breiter Anbindung. Die VHDL-Seite im FPGA musst du dir selber schreiben. Der FT2232H hat den Vorteil, dass du keine eigene vendor-ID benötigst, du darfst die von FTDI nutzen.
Ah zum Ethernet nochmal: Genau sowas meinte ich, wir hatten den WizNet Chip im Hinterkopf...wie ist es denn bei dem Chip (zb. dem WizNet W5300), kann man da noch irgendwie DHCP implementieren oder geht das nur mit dem etwas größeren Chip inkl. MCU ?... Zum USB-Chip: Ich find die FTDI Doku relativ nichtssagend, daher hatte ich auch hier nachgefragt...die Cypress Doku ist wenigstens detaillierter... Wie ist das mit den Vendor-IDs, gibts da sonne Art Lizensierung oder wie muss ich mir das vorstellen ? lg marcel
Naja, WizNet kann ja nur 100MBit maximal. Zur FTDI Doku. Da ist doch alles wichtige beschrieben. Der synchrone FIFO-Modus ist das sinnvollste für FPGA würde ich denken. Alle Ablauf-Diagramme mit Timings sind angegeben (Sektion 4.4 im datenblatt), also wo ist das Problem? Jedes USB Gerät braucht eine Vendor ID und eine Produkt ID. Willst du Geräte verkaufen, musst du eine eigene Vendor ID beantragen. Das kostet einmalig 2000 USD bei der USB.org und man darf dann 65536 verschiedenartige Geräte verkaufen. FTDI ist da eine löbliche Ausnahme. Auf Anfrage bekommt man von denen einen Block von 8 Product IDs, die man zusammen mit deren Vendor ID und nur zusammen mit FTDI Chips benutzen darf. Man darf also 8 verschiedenartige Geräte bauen/verkaufen damit und auch das Inf-File des Treibers auf die eigene Firma anpassen. Gleiche Geräte untereinander unterscheiden sich in der Seriennummer, die kann man als String in die Firmware des USB Controllers eintragen. Geht bei FTDI mit dem MPROG Utility.
> Naja, WizNet kann ja nur 100MBit maximal. Das ist mir durchaus bewusst... ob das Ding jetzt 8 MB/s oder 28 MB/s hat ist für unsere Anwendung relativ egal, schneller ist zwar meistens besser, Ethernet hat aber nen paar andere Vorteile, daher trotzdem die Frage zu dem WizNet Chip ;) ---- Aber ich seh es schon richtig, dass bei 245 FIFO sync Mode der zweite Channel nicht mehr anderweitig verwendet werden kann, z.b. für JTAG? lg marcel
Naja, du kannst die beiden Kanäle bündeln oder einzeln betreiben: # USB to parallel FIFO transfer data rate up to 10Mbyte/sec. # Single channel synchronous FIFO mode for transfers > 25 Mbytes/sec.
Ich wollte für unser Projekt auch unbedingt, dass unser FPGA Modul einer USB Standard Klasse angehört, damit wir keine Treiber entwickeln bzw. auf verschiedenen Plattformen PFLEGEN müssen. Für den USB Chip gabs damals keine Evaluation, es stand schon fest den Cypress FX2 zu nehmen. Aus verschiedenen Gründen, die nicht unbedingt nachvollziehbar sein müssen :-), habe ich mich für USBTMC (Test and Measurement Class) entschieden, ist im Prinzip das USB basierte physical layer zu IEEE488 (vielleicht als GPIB geläufig, die Ethernet Variante heisst LXI). Dazu noch die DFU Klasse damit man ein Firmware update mit schon vorhandenen Tools (dfu-util) machen kann. Schönes Konzept das nun auch endlich stabil funktioniert. War eine heiden Arbeit die verdammt viel Zeit gekostet hat. Der FX2 Codespeicher war viel früher voll als angenommen und bis am Schluss musste ich immer wieder Codeoptimier runden machen und hatte kaum platz für 3 bis 4 printf's, was das überhaupt einzige war (Ausser meinem treuen USB analyser) was mir zum debuggen zur Verfügung stand. Resultat ist mit linux usbtmc treiber (nicht der kernel treiber, der alte...) das ich mit ca. 23 MiB/s daten zum FPGA schaufle und der Treiber mir ein Bein stellt und ich nur 2,5 MiB/s daten vom FPGA lesen kann. Nach all dem wünschte ich mir eine Evaluation gemacht zu haben, so hätten wir wahrscheinlich den FTDI Chip bei uns getestet und uns erst danach entschieden. Für mich ist es eine grosse lehre, bei einem uC sehr genau darauf zu achten wie gut die Möglichkeiten sind nach Fehlern zu suchen. Der FX2 hat mir keine Freude gemacht. Für alle die unsere Arbeit interessiert: http://labs.ti.bfh.ch/gecko/wiki/systems/gecko3com/start http://opencores.org/project,gecko3 Alles was zum GECKO3 Projekt gehört ist opensource und im opencores.org SVN Repository zu finden (Altium, Gerber, VHDL, C files und libraries) Das Bild auf opencores.org mit dem Modul Stack ist kein Fake, die Module sind wirklich so skalierbar!
Christoph Z. schrieb: > Für mich ist es eine grosse lehre, bei einem uC sehr genau darauf zu > achten wie gut die Möglichkeiten sind nach Fehlern zu suchen. Der FX2 > hat mir keine Freude gemacht. Hallo Christoph, Das kann ich gut verstehen. Weil der FX-2 teilweise schwer zu beherrschen ist haben wir aus der Not eine Tugend gemacht und liefern mit unseren FPGA boards eine selbst entwickelte FX-2 Firmware plus Treiber und API mit. Außerdem eine Beispiel Implemenierung einer Wishbone-FX2 Brücke. Dieses Paket heisst bei uns UDK (unified development kit) und ist ziemlich ausgereift da es seit Jahren in vielen hundert Projekten eingesetzt wurde. Die Schaltpläne der FPGA Karten mit FX-2 können kostenlos auf unserer webseite www.cesys.com runtergeladen werden. Das UDK gibt es aber leider nicht kostenlos sondern nur in Verbindung mit einer Cesys Karte. Bevor es das UDK gab haben wir die FPGA-FX2 Verbindung per GPIF gemacht. Das hat zwar funktioniert, aber das GPIF-timing war im FPGA fast nicht hinzubekommen. Inzwischen läuft alles im slave-FIFO mode des FX-2 und funktioniert schnell und problemlos.
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.