Forum: Mikrocontroller und Digitale Elektronik Mkrocontroller und 100 MBit/s Ethernet


von Schmidi (Gast)


Lesenswert?

Hallo Leute!

Ich habe da mal eine kleine Frage: Fuer ein Projekt wuerde ich einen
Mikrocontroller und ein 100 MBit/s Ethernet Interface benoetigen.

Der Controller sollte im wesentlichen Daten von I/O Pins 8 oder 16
Bit-weise einlesen, etwas Headerinfo dazubasteln und als Ethernet Paket
senden. Timing ist nicht kritisch da ich vor dem Controller ein
groesseres FIFO habe. Der Durchsatz ist leider wichtiger. Es sollen so
ca. 50 MBit/s daruebergehen. Am besten waere da ein Controller mit
eingebauten Ethernet MAC (oder vielleicht sogar PHY) und integrierten
Flash + RAM (ein paar zig kByte zum buffern). Dachte da z.B. an einen
AT91SAM7X...

Habt Ihr schon Erfahrung mit einer solchen Anwendung? Wie schauts mit
den on-Chip Ethernet Controller aus? Kriegt man da via DMA auch
groessere Datenmengen schnell raus? Kann mir jemand eine Alternative
zum AT91 empfehlen?

Vielen Dank,
Schmidi

von A.K. (Gast)


Lesenswert?

50Mbps sind in der angepeilten Controllerklasse grob 1 Bit pro
Prozessortakt. Allein die Daten von den Pins abzuholen wird bei der
Rate schon schwierig.

von Schmidi (Gast)


Lesenswert?

Naja, ich denke mir wenn man die Daten mit jeweils 16 Bit liest sollte
es schon fuer eine einfache "Copy from IO Pin to Ram" Schleife
reichen (so. 5-6 Befehle / 16 Bit). Der AT91SAM7X sollte dann ja die
Daten via DMA ueber Ethernet uebertragen koennen (soweit ich das im
Datenblatt auf den ersten Blick sehe). Da ich ja einen Fifo an den IO
Pins habe sollte ich also ein ganzes Paket (sagen wir mal 1000 Byte)
in ca. 1000/2 * 6 = 3000 Zyklen auf einmal lesen koennen. Fuer das
Prozessing bliebe dann noch so 50 MBit/8 = 4 MByte/s / 1000 Byte = 4000
Pakete/s => 4000 x 3000 => 12 Millionen Zyklen/s fuer das einlesen => 30
Millioen Zyklen/s uebrig.

Soweit die Theorie (ganz naiv) - Nur funktioniert das auch in der
Praxis?
Habe leider (noch) keine Erfahrung mit dem AT91SAM7x...

Viele Gruesse,
Schmidi

von A.K. (Gast)


Lesenswert?

Müssen die Daten von den I/O-Pins irgendwie quittiert werden? Wenn da
extern ein FIFO dranhängt, dann wird ja wohl eine wenngleich minimale
Transfersteuerung fällig (sowas wie "Strobe setzen, Daten abholen,
Strobe löschen").

Und wenn du Pech hast, dann braucht der Prozessor für I/O-Zugriffe
etwas länger als die üblichen 2-3 Takte die er im RAM braucht, weil
über langsameren Periphierebus.

Rechne also lieber mal zusammen, was allein der Blocktransfer "I/O zu
RAM" mindestens an Zeit braucht.

Was den Transfer angeht: Ist da TCP/IP beteiligt, oder ist das nacktes
Ethernet? TCP/IP frisst zusätzliche CPU-Leistung.

von A.K. (Gast)


Lesenswert?

Apropos "5-6 Befehle / 16 Bit" in 6 Takten: Speicherbefehle benötigen
auf ARM7 mitnichten nur einen Takt. LDR=3, STR=2 Takte. Minimum.

von Schmidi (Gast)


Lesenswert?

Hallo A.K.!

Danke für die Antwort. Muß einen Takt vorgeben - bin in dieser Hinsicht
aber flexibel da der Fifo in einem FPGA ist und ich den VHDL Code leicht
ändern kann. Also ein XOR IOPin,IOPin oder so sollte für den Takt in der
Schleife reichen - das genaue Timing kann ich dann im FPGA anpassen.

Nacktes Ethernet würde mir genügen. Also nur Daten + ein paar Header
Fields.

Das gewisse Latenzzeiten beim Speicherzugriff auftreten hab ich mir
fast gedacht. (Nur halt nicht wahrhaben wollen ;-). Muß mir das
Datenblatt noch mal genauer anschauen.

Im schlimmsten Fall müsste ich einen externen Ethernet MAC über den
FPGA an einen Mikrocontroller anbinden und das Bulk-Daten-Kopieren vom
FPGA aus machen. Nur dann wird das synchronisieren mit dem
Mikrocontroller relativ kompliziert (Muss im Hintergrund auch ab und zu
andere Daten lesen und senden - so ca. 1-2 kByte/s) - ich möchte ja
nicht unbedingt zwei Ethernet MACs verwenden.

Viele Grüße
Schmidi

von A.K. (Gast)


Lesenswert?

"XOR IOPin,IOPin"

Naja, mit ARM hat das wenig zu tun.

Die Minimalversion sieht als Schleife eher so aus, allein für den
Transport von I/O zu Speicher (vereinfacht formuliert):
   str  reg1, ioport_set    ;2+n
   ldrh reg2, ioport_read   ;3+n
   str  reg1, ioport_clr    ;2+n
   strh reg2, buffer++      ;2
   subs reg3, reg3, 1       ;1
   bne  ...                 ;2
Da sind wir schon bei 12 Takten. Mit 8 Bit wird das somit sicher
nichts. Und auch die 12 Takte gelten nur, wenn die I/O-Zugriffe nicht
vom I/O-Bus ausgebremst werden - was indes bei ARM7-Implementierungen
öfter vorkommt.

von Jörn (Gast)


Lesenswert?

was für ein FPGA hast drauf? Wäre ein Microblaze oder NIOS II eine
Möglichkeit?

Gruß Jörn

von Schmidi (Gast)


Lesenswert?

@AK: Danke fuer die Infos. Wie gesagt, leider habe ich noch keine
Erfahrung mit den ARM Controllern. 12 Zyklen/2 Byte wuerde den
Durchsatz auf theoretisch maximal 8 MByte/s limitieren.
Weisst Du vielleicht wie es mit dem DMA Controller des Ethernet MACs im
SAM7X ausschaut? Denke mir mal das dieser fuer die Dauer des DMA
transfers die Speicherzugriffe sperren oder zumindest verlangsamen
wird?

@Jörn: Derzeit einen Xilinx Spartan 2 (30)- Kann aber leicht auf einene
groesseren ausweichen (e.g. Spartan 3 400). An Microblaze habe ich auch
schon gedacht - leider aber auch hier noch keinerlei Erfahrung... Muss
mal schauen was man dafuer alles braucht (EDK,...)... Vielleicht ist es
wirklich eine Alternative. Einen Ethernet MAC Core gaebe es ja bei
OpenCores - nur ob ich mich ueber sowas daruebertraue...

Vielen Dank
Schmidi

von A.K. (Gast)


Lesenswert?

Ich kenne den DMA vom SAM7X auch nicht, gehe aber davon aus, dass er
extra Zeit rauben wird - schliesslich muss er die gleichen Pfade nutzen
wie die CPU. Evtl. vergleichbar einem zusätzlichen IO-Load und
RAM-Store.

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.