Hallo, habe mal eine Frage. Suche eine Möglichkeit mit so wenig wie möglich Hardwareaufwand (!) eine High Speed Schnittstelle vom PC zum FPGA Design zu implementieren. Was ich schonmal fertig entwickelt hatte ist eine UM232H von FTDI in High Speed Mode zu implementieren. Erreicht hatte ich damals eine max. Speed von ca. 45MBytes/s. Brauche aber min. 16 Pins um das an meinem FPGA ranzubekommen. Da ich nun nicht viele Pins übrig habe stellte ich mir die Frage ob es nicht möglich ist sich direkt mit einer USB-Schnittstelle am PC zu verbinden. Eine 5V to 3V3 Wandlung wird natürlich nötig sein. Aber die IP im FPGA muss sich halt als USB Interface ausgeben. Frage ist, gibt es sowas schon fertig als IP-Core. Kostenlos oder auch gegen Aufpreis. LG
Bei opencores könnts was geben.. Wandeln von 5 V hört sich nicht gut an, du müsstest direkt an die differenziellen Pins von deinem FPGA drangehen.
ja da findet sich was :-) was ich noch nicht ganz verstehe. Wenn ich jetzt so eine USB 2.0 IP Core habe, angebunden über einen differenziellen Eingang, verbunden am PC erkennt der PC mich dann als USB High Speed? Welche DLLs werden verwendet oder wie binde ich dann das ganze in meine Software ein? Bei FTDI Chips hat man entsprechende DLL welches man in die software "wrappen" kann. Wie macht man sowas wenn man eine IP Core hätte.
User schrieb: > erkennt der PC mich dann als > USB High Speed? Der PC erkennt überhaupt nur etwas, wenn der Pullup an D+ dran ist. Dann spricht er das Device per Full Speed an, fragt die Deskriptoren ab, stellt fest dass das Gerät High Speed kann, und schaltet es mit den entsprechenden Befehlen um. User schrieb: > Welche DLLs werden verwendet oder wie binde ich dann das > ganze in meine Software ein? Es wird die VID/PID und Geräte-Klasse abgefragt und der entsprechende Treiber geladen, bzw. der User aufgefordert einen Treiber zu installieren. Du musst also einen Treiber programmieren. Alternativ kannst du eine Standardklasse wie USB-CDC implementieren und den PC den Standard-Treiber laden lassen, z.B. usbser.sys. Um auf diesen aus der Anwendung zuzugreifen benutzt du dann die normalen Win32-API DLL's für Serial-Port Zugriff. Wenn du einen eigenen Treiber baust, musst du eigene DLL's entwickeln bzw. aus der Anwendung anders auf den Treiber zugreifen. Du kannst auch den winusb.sys Treiber laden lassen, dann kannst du über das WinUSB API oder libusb zugreifen; dadurch entfällt die Treiber-Entwicklung und -Signatur (ab Win 10). FPGA USB Cores arbeiten doch bestimmt auch mit einer CPU oder? USB komplett in Logik zu implementieren stelle ich mir extrem aufwendig vor.
@Dr. Sommer Dass das ganze Aufwendig wird ist mir schon klar. Doch ich suche eine Lösung ohne Aufwand gegen Aufpreis (weiss nicht wieviel sowas kosten würde). Im Klartext nochmal: - Eine IP Core der alles zum USB 2.0 enthält, wo die Daten quasi nur noch über FIFOs gelesen und geschrieben werden können - Software mit Treiber oder DLL sollte mit Beispielcode vorhanden sein. - Damit will ich dann mit wenig Aufwand das ganze bei mir im FPGA und in meiner Testsoftware (C oder Delphi)implementieren Oder ich muss halt auf meine Lösung mit dem UM232H Board zurückgreifen und Pins dafür freischaufeln :-)
User schrieb: > Doch ich suche eine > Lösung ohne Aufwand gegen Aufpreis (weiss nicht wieviel sowas kosten > würde). Hä? User schrieb: > - Eine IP Core der alles zum USB 2.0 enthält, wo die Daten quasi nur > noch über FIFOs gelesen und geschrieben werden können Ich bin jetzt kein FPGA-Experte, aber ein solcher Core würde wahrscheinlich eine Soft-CPU enthalten/benötigen, mit passender Firmware natürlich. User schrieb: > - Software mit Treiber oder DLL sollte mit Beispielcode vorhanden sein. Also ein Rundum-Sorglos-Paket. Glaube kaum dass jemand so etwas verschenkt. Wenn du keine eigenen Treiber entwickeln willst, geht so etwas mit WinUSB. USB ist kompliziert, und USB-HS nochmal ganz besonders. In UM232H & Konsorten steckt schon einiges drin. User schrieb: > Oder ich muss halt auf meine Lösung mit dem UM232H Board zurückgreifen > und Pins dafür freischaufeln :-) Das ist wahrscheinlich sehr viel einfacher... Ganz anderer Vorschlag: Einen uC mit integriertem USB-HS-PHY nehmen, z.B. einen der STM32F7x3-Reihe. Da kannst du das ganze USB-Protokoll drin abhandeln, und über irgendeine schnelle Schnittstelle (FSMC? SDIO?) zum FPGA schaufen. Wäre quasi ein UM232H-Nachbau.
Ich glaube du stellst dir das etwas zu einfach vor. Auch der USB 2.0 Core von Open Cores benötigt einen USB 2.0 PHY. Sonst bräuchtest du einen Super Super FPGA, der die 480MHz an den I/Os kann. Kann vielleicht der Xilinx Kintex oder schneller. Auf der Treiber-Seite kannst du einfach WinUSB oder LibUSB nehmen, aber eine Vendor ID müsstest du dann auch noch kaufen. Vielleicht solltest du lieber beim FTDI Chip bleiben...
User schrieb: > Da ich nun nicht viele Pins übrig habe stellte ich mir die Frage ob es > nicht möglich ist sich direkt mit einer USB-Schnittstelle am PC zu > verbinden. Eine 5V to 3V3 Wandlung wird natürlich nötig sein. Aber die > IP im FPGA muss sich halt als USB Interface ausgeben. Wenn das FPGA keine USB-fähigen Transceiver bereits enthält, musst Du einen externen anschließen. Z.B. den hier: http://www.ti.com/lit/ds/symlink/tusb1210.pdf Wenn Du das Datenblatt sowohl gelesen als auch verstanden hast, dann wird Dir klar sein, dass Du entweder ein sehr schnelles FPGA brauchst, oder dass Du beim Pincount nichts sparst. Das einfachste wäre einfach ein FPGA mit mehr Pins. fchk
Christian R. schrieb: > Sonst bräuchtest du > einen Super Super FPGA, der die 480MHz an den I/Os kann. Kann vielleicht > der Xilinx Kintex oder schneller. Nope, da gehen weitaus mehr in niederigeren Preisregionen. Ausserdem sind es nicht 480 MHz sondern 480 MB/s - Spartan 6/7 - Artix 7 Allein von Xilinx. Lattice MachXO2/3 und Crosslink schaffen auch die 480 MB/s. Die Xilinx Devices gehen teilweise bis 1 GB/s und mehr (an den User IOs nicht MGTs!), das ist also nicht das Problem. Ich bin kein Experte fuer USB, aber mir scheint das groesste Problem ist wirklich der PHY. Ich finde auch keine Anwendung die ohne auskommt. Evtl. ist man da mit den Zynqs besser bedient, die koennten USB schon komplett mitbringen, dann allerdings im PS und nicht PL System.
Tobias B. schrieb: > Nope, da gehen weitaus mehr in niederigeren Preisregionen. Ausserdem > sind es nicht 480 MHz sondern 480 MB/s Nein, es sind 480 MHz und 60 MByte/s (brutto) bei USB-High Speed. Tobias B. schrieb: > Ich bin kein Experte fuer USB, aber mir scheint das groesste Problem ist > wirklich der PHY. Und das ziemlich komplizierte Protokoll. Schau dir mal die ganzen total übersichtlichen Zustandsdiagramme in der USB-Spezifikation an... :-)
Dr. Sommer schrieb: > Nein, es sind 480 MHz und 60 MByte/s (brutto) bei USB-High Speed. In jedem Dokument finde ich, dass USB 2.0 bis maximal 480 MB/s spezifiziert ist. Ich denke offizieller wie: https://www.usb.org/document-library/usb-20-specification wird es nicht. ;-) Edit: Jetzt seh ich das Problem. Es sind 480 Mb/s, nicht Byte. War richtig gemeint von mir aber falsch geschrieben, mein Fehler. :-) Dr. Sommer schrieb: > Und das ziemlich komplizierte Protokoll. Schau dir mal die ganzen total > übersichtlichen Zustandsdiagramme in der USB-Spezifikation an... :-) Das ist erstmal kein Problem, FPGAs loesen viele komplizierte Aufgaben, da wird man auch das Protokoll unterbringen. Auf dem untersten Layer ist das auch nicht wirklich kompliziert, erst die oberen Layer sorgen fuer Komplexitaet wenn man wirklich jeden Teilaspekt implementieren will. In der Regel reichen jedoch fuer spezielle Aufgaben auch nur die benoetigte Teilmenge zu implementieren.
Tobias B. schrieb: > In jedem Dokument finde ich, dass USB 2.0 bis maximal 480 MB/s > spezifiziert ist. Auf S. 1 der Spezifikation steht: "USB 2.0 addresses this need by adding a third transfer rate of 480 Mb/s". Kleines "b", also Bit! Auf S. 7 steht: Mb/s Transmission rate expressed in megabits per second. MB/s Transmission rate expressed in megabytes per second. Hier steht es nochmal ganz klar: https://de.wikipedia.org/wiki/Universal_Serial_Bus#Datenraten Die Nutzdatenrate ohne Protokolloverhead ist 40 MB/s.
Jep, habs dann auch gesehen, war aber wirklich nur ein Schreibfehler, hatte 480 Mb im Kopf aber ausversehen MB geschrieben. Macht aber die obige Aussage mit den verschiedenen FPGAs die in Frage kommen koennen, nicht falsch. 480 MBytes/s waeren auch voellig utopisch auf User IOs und nur mit MGTs zu schaffen.
Tobias B. schrieb: > Nope, da gehen weitaus mehr in niederigeren Preisregionen. Ausserdem > sind es nicht 480 MHz sondern 480 MB/s > > - Spartan 6/7 > - Artix 7 Schon, aber dann müsste man das über die SERDES hinbekommen, und da hab ich zumindest noch keinen Core gesehen der das kann. Im PHY Layer von USB stecke ich auch nicht so tief drin, kann sein dass sich das nicht so ohne weiteres mit den SERDES machen lässt. Da gibts ja einige Sonderzustände der beiden Datenleitungen und bidirektional ist auch alles. USB 3.0 wiederum ist am PHY auf dem FPGA kein Thema, wenn man MGTs hat. Aber auch da kostet ein Core einige Tausender zzgl. DMA Core.
Christian R. schrieb: > Schon, aber dann müsste man das über die SERDES hinbekommen, und da hab > ich zumindest noch keinen Core gesehen der das kann. Im PHY Layer von > USB stecke ich auch nicht so tief drin, kann sein dass sich das nicht so > ohne weiteres mit den SERDES machen lässt. Ob SERDES verwendet werden muss oder nicht ist unerheblich. SERDES schraenkt in dieser Hinsicht die Funktionalitaet 0 ein. Ich muss halt die Daten im Vorfeld parallel prozessieren, das ist aber wirklich kein Problem. Wenn ich mal so ganz grob ueberblicke, dann besteht der erste Datenlayer hauptsaechlich aus: - NRZI Coding - Bit Stuffing - CRC Das "komplizierteste" ist dabei das Bit Stuffing, was sich jedoch mit einem FIFO auch relativ easy handhaben laesst. Das Problem scheint mir das ganze drum herum zu sein auf PHY Level. USB ist halt mehr als einfach nur ein Bidirektionaler LVDS Channel und da steigt ein FPGA ohne spezielles USB PHY leider aus. :-(
Tobias B. schrieb: > Das Problem scheint mir das ganze drum herum zu sein auf PHY Level. USB > ist halt mehr als einfach nur ein Bidirektionaler LVDS Channel und da > steigt ein FPGA ohne spezielles USB PHY leider aus. :-( Allerdings. Alleine das Gemache mit den Pull Widerständen...
Also wär jetzt die moderne Variante eine Kombination aus: - Low-speed USB selber gebaut wie seit Jahren bekannt als "Virtual-USB" VUSB für den AVR. Dient nur dazu, damit das OS Deskriptoren auslesen kann. - USB Super-speed per FPGA SERDES implementieren. Nur mal so als Idee in den Raumgestellt :-) Korrigiert mich, fresst mich auf, wenn ich etwas offensichtliches übersehen habe. Oder ist das in USB 3 sogar vorgesehen, dass man gar keinen Low-speed/Full-speed Kanal brauch um sich anzumelden?
Ich habe mal auf meinen ZCU106 Evalboard geschaut. Da ist USB 3.0 ueber die MGTs eines PS-GTRs und der USB 2.0 Teil wird via eines Microchip USB3320 realisiert. Die LVDS Lanes des MGTs gehen dafuer direkt an den USB 3.0 Stecker (nur ein paar ESD Dioden sind mit drauf) ohne zwischen PHY. Jetzt muesste man mal schauen ob PHY technische sich die PS-GTRs von denen im PL Teil eines Zynqs unterscheiden.
Christophz schrieb: > Oder ist das in USB 3 sogar vorgesehen, dass man gar keinen > Low-speed/Full-speed Kanal brauch um sich anzumelden? Ja, das ist vorgesehen, funktioniert auch und ist gemäß USB-Spec erlaubt, sofern es eine interne Verbindung auf Leiterplattenebene ist. Eine externe USB 3.0 Buchse muss laut Spec. hingegen auch mit Full-Speed (!, deswegen scheidet VUSB aus) gehen. Es wäre technisch nicht nötig, wenn Du damit zufrieden wärst, dass das Teil nur an USB3 enumeriert, aber Du darfst das dann eben nicht als "USB" bezeichnen. Damit will man Reklamationen von Endusern verhindern, was bei kommerziellen Produkten durchaus extrem sinnvoll ist. Handbücher liest ja eh niemand. fchk
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.