480 MBit USB wird von vielen schon als lahm bezeichnet. Ich frage mich, wie man sowas überhaupt realisiert. Mein xmega braucht für 12 läppische MBit schon eine 48 MHz CPU. Wenn ich das jetzt einfach mal stur hochrechne, brauche ich für 480 MBit ja eine fast 2 GHz CPU??? Von den USB 3.0 Geschwindigkeiten fange ich gar nicht mal an. Wo ist da der Trick???
Mit DMA. So ein USB-Chip hat Hardware, die ohne Umweg über die CPU direkt auf den Speicher zugreift.
Christian S. schrieb: > Wo ist da der Trick??? Nicht zu versuchen, es mit programmiertem Pingewackel zu schaffen.
Genauer gefragt: Laufen diese ASICs und FPGAs dann wirklich mit 2 GHz? Und wie ist das mit den höheren Geschwindigkeiten? z.B. 10 GBit. Schalten die dann wirklich mit 40 GHz? Geht das überhaupt?
> Laufen diese ASICs und FPGAs dann wirklich mit 2 GHz? Nein, nur die (De)Serialisierungseinheiten. Das sind dann eben spezielle High-Speed-Flipflops. > Und wie ist das mit den höheren Geschwindigkeiten? z.B. 10 GBit. > Schalten die dann wirklich mit 40 GHz? Geht das überhaupt? Wieso 40? 4fach Oversampling braucht man nicht unbedingt. Aber ansonsten geht das schon, ist aber weder billig noch stromsparend ;) Der Witz ist ja, dass nur relativ wenige FFs so schnell sein müssen.
:
Bearbeitet durch User
Christian S. schrieb: > 480 MBit USB wird von vielen schon als lahm bezeichnet. Naja. Solche "Fachleute" gibt es überall. > Ich frage mich, wie man sowas überhaupt realisiert. Mein > xmega braucht für 12 läppische MBit schon eine 48 MHz CPU. > Wenn ich das jetzt einfach mal stur hochrechne, brauche > ich für 480 MBit ja eine fast 2 GHz CPU??? Nee. MFM kann 2bit/Hz übertragen. Für 480MBit braucht man also 240MHz Takt. Das ist fast Faktor 8 effizienter als Dein xmega.
Ich hab z.B. ein FPGA Design mit dem Cypress FC3, der FX3 kriegt die Daten dort parallel mit 32 Bit bei 100MHz Takt, ergibt 400MB/s. Im FPGA keine Hexerei. Der FX3 ist ein Arm 9 mit USB Transceiver, der DMA schaufelt ohne CPU die Daten da rum.
:
Bearbeitet durch User
Na aber wie willst du parallelisieren, wenn die Daten nunmal seriell mit 480 MBit reinkommen? Da musst du ja trotzdem knapp 1 Mrd mal pro Sekunde abtasten.... Ich hätte nie gedacht, dass man über ein mehrere Meter langes Kabel 1 Mrd mal pro Sekunde den Pegel wechseln kann... Muss ein Supraleiter sein ^^
Christian S. schrieb: > Na aber wie willst du parallelisieren, wenn die Daten nunmal > seriell mit > 480 MBit reinkommen? Da musst du ja trotzdem knapp 1 Mrd mal pro Sekunde > abtasten.... Ich hätte nie gedacht, dass man über ein mehrere Meter > langes Kabel 1 Mrd mal pro Sekunde den Pegel wechseln kann... Muss ein > Supraleiter sein ^^ Wie oben schon gesagt: In dem die Deserialisierungseinheit (Seriell zu Parallel Wandler ganz superfixe Logik ist, die mit sehr hoher Taktfrequenz läuft). Die Daten kriegt man mit impedanzkontrollierten differentiellen Leitungen mit niedrigem Spannungshub über das Kabel. Da geht so einiges.
Wo ist das Problem? Man kann heutzutage problemlos Prozessoren bauen, die mit mehreren GHz laufen. So ein Prozessor besteht aus Millionen von Transistoren. Für USB müssen das nur eine Hand voll Transistoren, der Rest des Chips kann langsam arbeiten. Und über einen Kabel kann man noch viel schneller Daten übertragen. 10 GBit ist überhaupt kein Thema (USB3, SATA, Display-Port arbeiten alle in der Größenordnung). Mit Supraleiter hat das natürlich nichts zu tun. Der ohmsche Widerstand spielt da überhaupt keine Rolle, weil keine Leistung übertragen wird.
Christian S. schrieb: > abtasten.... Ich hätte nie gedacht, dass man über ein mehrere Meter > langes Kabel 1 Mrd mal pro Sekunde den Pegel wechseln kann... Muss ein > Supraleiter sein ^^ Nein, ein Wellenleiter. Das ist der Trick. Du hast noch eine Gleichstromdenke. Beschäftige Dich mal richtig mit Hochfrequenztechnik. Wenn Du dann erfährst, dass Du einen Kurzschluss durch Einfügen einer Leitung in einen Leerlauf umwandeln kannst (und umgekehrt), dann kommt vielleicht der Aha-Effekt (oder der Oha-Effekt). fchk
Im Prinzip ist das eigentlich trivial. Du hast erst mal ganz schnelle Schieberegister für die (De-)Serialisierung. Die arbeiten mit Bittakt (z.Bsp. 480 MHz) und geben dann die Datenwörter im Worttakt aus. (z.Bsp 480 MHz/8=60MHz) Dann haben die entweder DMA auf den Hauptspeicher des Systems oder eigenen Speicher. Mit DMA greifen die einfach mit 60 MHz auf den Speicher zu, mit einem eigenen Speicher haben die was exklusives. Bei DMA muss der Prozessor dafür sorgen, dass die USB Rahmen im RAM vorliegen und dann einen Befehl zum Senden geben, bei separaten Speicher muss er einfach den Speicher füllen, kann sich dafür aber beliebig Zeit lassen, weil ist ja USB da resettet der Bus eh die meiste Zeit.
Den Begriff "Rahmen" als deutsches Wort für "Frame" habe ich zuletzt in der Ausbildung vor zig Jahren gehört. Und es hat mich da schon gegruselt ;-)
Simon K. schrieb: > Den Begriff "Rahmen" als deutsches Wort für "Frame" habe ich zuletzt in > der Ausbildung vor zig Jahren gehört. Und es hat mich da schon gegruselt > ;-) Ich bitte um Aufklärung. Nein, nicht das mit Bienchen und Blümchen. Was ist denn das in dem Zusammenhang richtige deutsche Wort? ;-)
Dussel schrieb: > Ich bitte um Aufklärung. Nein, nicht das mit Bienchen und Blümchen. Was > ist denn das in dem Zusammenhang richtige deutsche Wort? Wer verstanden werden will schreibt Frame und Byte, wer solche sinnlosen Diskussion will schreibt Rahmen und Oktett. ;-)
:
Bearbeitet durch User
Und was ist, wenn im Englischen schon octet steht? Wenn ich das mit Byte wiedergebe, unterschlage ich die implizite Warnung bezüglich des Fernmeldetechnik-Hintergrunds (wer octet schreibt, fängt auch bei 1 an zu zählen. Und nummeriert&serialisiert seine Bits in merkwürdigen Richtungen)
TU Dresden: ¯¯¯¯¯¯¯¯¯¯¯ Programmverbinder -> Linker Verarbeitungseinheit -> CPU Befehlszähler -> Program Pointer Kellerspeicher -> Stack Pointer usw. http://tu-dresden.de/die_tu_dresden/fakultaeten/fakultaet_elektrotechnik_und_informationstechnik/ifn/kn/lehre/lehrveranstaltungen/mrt1/ANL_SIM.pdf * scnr * Der FTDI FT2232H ist recht fix, aber teuer. Falls das jemandem hilft.
:
Bearbeitet durch User
Der Poster sollte vielleicht mal SERDES nachschlagen. Es gibt Chips, die machen aus 32bit parallel an 32MHz 1GBit seriel und der partnerchip macht auf der anderen Seite wieder 32bit parallel an 32MHz
Gegen aktuelle FPGAs ist das Kindergarten, selbst die kleinen Artix machen über 6GBit/s an den MGTs.
Christian S. schrieb: > 480 MBit USB wird von vielen schon als lahm bezeichnet. Ich frage mich, > wie man sowas überhaupt realisiert. Mein xmega braucht für 12 läppische > MBit schon eine 48 MHz CPU. Das ist ein bissel Quatsch. Also: die meisten USB-Cores arbeiten mit einem äußerlichen Takt von 48 MHz. Das "äußerlich" betone ich, weil wohl kaum einer von uns hier feststellen kann, was so ein spezialisierter Peripherie-Core in seinem Inneren draus macht. VIelleicht läuft sowas innerlich mit 96 MHz oder weiß der Geier.. Das Nächste ist die tatsächliche Datenrate. Auf so einer USB-Strippe läuft ja einiges mehr als nur der Traffic von einem einzigen Endpoint. Da gibt es busintern eine Menge mehr an Traffic, als man es sich gemeinhin so vorstellt. Die 480 MHz sind aber nur ein Schlagwort für das Gesamte. Sie sind eben nicht gleichbedeutent mit der Annahme, daß man dort tatsächlich 60 MByte/Sekunde an Nutzdaten drüberkriegt. Fazit: immer mit der Ruhe... W.S.
Das macht man auf keinen Fall, indem man mit der Software aus der CPU irgendwelche GPIOs toggelt. Auf der CPU ist ein spezielles Hardware-Modul, der USB-Transceiver, der die ganze niedrige Protokollebene für dich abhandelt. Im Wesentlichen kopierst du die Daten die du senden willst in ein Transmit-Register. Auf einer 32-bit-CPU kannst du da also mit einer Instruktion (oder zwei oder was auch immer) 32 bits reinkopieren -- und schon kommst du mit 15 Millionen Instruktionen pro Sekunde auf die 480 MBit/s. Bisschen mehr Aufwand ist das auf Softwareseite in der Praxis schon, aber du brauchst auf keinen Fall eine 2 GHz-CPU um das umzusetzen. Interssant ist halt dass der Transceiver im Zweifelsfall einen Takt hat, der deutlich über dem CPU-Takt liegt.
:
Bearbeitet durch User
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.