mikrocontroller.net

Forum: FPGA, VHDL & Co. Ethernet GMII


Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe einen FiFo geschrieben, der als Zusatzfunktion den Ethernet 
frame miterzeugt. z.B. ein Softcore schreibt auf den Fifo und wenn alles 
fertig ist, wird das Paket gesendet.
Das nteressante File ist  ether_tx.vhd

eintakt.vhd erzeugt den 125Mhz takt.

ether_top.vhd ist ein Testfile, das ständig ein Paket auf den Fifo legt 
und sendet.

tb_ether_top.vhd ist eine Testbench


zurück zu ether_tx.vhd

Es sind zwei STMs. Eine zum Einlesen und eine zum Senden.



Die Daten werden immer in den Fifo geschrieben und mit dem Signal 
"store_CRC" wird Das Datenpaket abgeschlossen. Der CRC32 wird noch auf 
den Fifo geschrieben.
Gleichzeitig wird die zweite STM angeschoben und bevor der FiFo 
ausgelesen wird, wird das Preable des Ethernetframes gesendet.

Die Simulation für das Verhalten simuliert genau was ich erwarte.
Der Code läst sich synthetisieren und in den FPGA laden. Die Link LED 
flackert am PC. Leider kann ich mir Wireshark keine Pakete lesen.
Es wird das Paket verworfen vom Betriessystem.

Ich bin schon länger dran und komme irgendwie nicht weiter. Es gab in 
dem Forum schon mal zum Thema Ethernet ein paar Diskussionsrunden. Ich 
hoffe auf die alten Freaks.


Es hängt am Unwissen folgender Punkte:
-Wie ich mit ISIM eine Post-Simulation durchführen kann?
-Irgend etwas nicht beim GMII nicht beachtet?
-Höhere Constrain Anweisungen, ich habe es nicht geschaft in das UCF 
File die Taktleitungen aus der DCM als Taktleitungen mit 125MHz zu 
definieren.

Der Code hat noch Fehler wie der Fifostand, doch mein Testpaket wird 
versendet. Leider eben doch nicht.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Leider kann ich mir Wireshark keine Pakete lesen.
> Es wird das Paket verworfen vom Betriessystem.

Unter Windows weiss ich es nicht, unter Linux ist das garantiert nicht 
der Fall. Da kommt zum wireshark/tcpdump auch noch der grösste Mist 
durch ;) Allerdings sollte man für solche Tests auch Netzwerkkarten 
nehmen, die nicht zuviel Intelligenz haben. Als sehr tauglich haben sich 
zB. die Realtek-Gbit-Teile (8168/8169 & Co) erwiesen. Die sind schnell, 
aber dumm... Es geht aus deiner Beschreibung nicht ganz hervor, aber bei 
solchen Tests sollten man auch keine Switches dazwischen haben, eine 1:1 
Verbindung ist das beste.

> Es sind zwei STMs. Eine zum Einlesen und eine zum Senden.

Geht denn der Empfangsteil?

Ich würde dann erstmal schauen, ob die Kommunikation überhaupt geht. 
D.h. ein einfaches Paket inkl. aller CRCs von Hand erzeugen und nur aus 
dem BRAM abspielen. Ich kenn PHY vom 601 nicht, aber evtl. könntest auch 
mal im PHY den internen Loopback anschalten und schauen, ob der 
Empfänger wiederum damit was anfangen kann.

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist dein frame lange genug dass er kein padding braucht, oder fügst du 
das padding ein bevor der frame in die fifo wandert?

Die GAP ist mehrere Takte lang. Soweit ich deinen code überflogen habe 
ist die bei dir nur 1 Takt lang? Die XPS Ethernet Lite Doku erläutert 
den Frameaufbau recht gut: 
http://www.xilinx.com/support/documentation/ip_doc... 
(Seite 3-5)

Probier mal, die nibble von pre7 zu swappen, also x"d5" statt x"5d".

Ansonsten noch ein paar andere Sachen die mir aufgefallen sind:
- den phy_nRST muss man hi setzen, auf unbenutzte IOs legt das ISE 
üblicherweise ja einen pulldown (da deine link-LED blinkt ist das aber 
vmutl. nicht dein problem)
- wenn der Link nicht 1000MBit/s ist, läuft der phy im MII statt GMII 
mode
- wenn ein switch dazwischen ist und die dst-macaddr. nicht stimmt (z.B. 
weil nibbles geswapped sind oderso) kommt natürlich auch nix an - oft 
hilfts, erstmal mit der broadcast dst_mac=ffffffffffff testen

Ich sitze z.Z. an nem kleinen core, der GMII und MII kann, bin nur 
gerade am neu strukturieren. Sobald der wieder tut was er soll können 
wir ja mal txd/en von den Simulationen vergleichen.

(Ich hab mir übrigens die 125MHz Synthese via DCM gespart, indem ich da 
einfach rxclk für verwende)

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hunz schrieb:
> Ist dein frame lange genug dass er kein padding braucht, oder fügst du
> das padding ein bevor der frame in die fifo wandert?

Das Gap ist noch zu kurz das ist richtig bemerkt. Es wir aber nur 1 
Paket pro Sekunde aktiviert. Das meinte ich, dass der Code noch nicht 
ganz Ok ist.

Die Gap sollte 12 Takte lang sein.
> Die GAP ist mehrere Takte lang. Soweit ich deinen code überflogen habe
> ist die bei dir nur 1 Takt lang? Die XPS Ethernet Lite Doku erläutert
> den Frameaufbau recht gut:
> 
http://www.xilinx.com/support/documentation/ip_doc...
> (Seite 3-5)

Das muss ich mit mal reinziehen.

>
> Probier mal, die nibble von pre7 zu swappen, also x"d5" statt x"5d".
>
> Ansonsten noch ein paar andere Sachen die mir aufgefallen sind:
> - den phy_nRST muss man hi setzen, auf unbenutzte IOs legt das ISE
> üblicherweise ja einen pulldown (da deine link-LED blinkt ist das aber
> vmutl. nicht dein problem)
> - wenn der Link nicht 1000MBit/s ist, läuft der phy im MII statt GMII
> mode
Bei der automantischen Neogitation geht auch die LED für 1000Mbit an.

> - wenn ein switch dazwischen ist und die dst-macaddr. nicht stimmt (z.B.
> weil nibbles geswapped sind oderso) kommt natürlich auch nix an - oft
> hilfts, erstmal mit der broadcast dst_mac=ffffffffffff testen

genau deshalb sind die ersten Bytes von meinem Testpaket 0xFF

> Ich sitze z.Z. an nem kleinen core, der GMII und MII kann, bin nur
> gerade am neu strukturieren. Sobald der wieder tut was er soll können
> wir ja mal txd/en von den Simulationen vergleichen.
>
> (Ich hab mir übrigens die 125MHz Synthese via DCM gespart, indem ich da
> einfach rxclk für verwende)

Interessante Idee,nur ich hatte beim Fitten die Fehlermeldung der 
Taktausgang ist schlecht gewählt. Ich soll ein ODDR benutzen, um den 
Takt auszugeben. Dafür brauche ich auch den Takt um 180Grad gedreht und 
dann bin ich wieder bei der DCM.

> die nicht zuviel Intelligenz haben. Als sehr tauglich haben sich
>zB. die Realtek-Gbit-Teile (8168/8169 & Co) erwiesen.
ich habe einen von Broadcom

>Ich kenn PHY vom 601 nicht, aber evtl. könntest auch
>mal im PHY den internen Loopback anschalten und schauen, ob der
>Empfänger wiederum damit was anfangen kann.
Die Idee ist ganz gut leider hat das Board keine sinnvollen Ausgaben. 
Nur vier LEDs, Einen Seriell zu USB, dessen USB Treiber bei mir nicht so 
richtig läuft. Da ist noch etwas im Argen.


>Unter Windows weiss ich es nicht, unter Linux ist das garantiert nicht
>der Fall. Da kommt zum wireshark/tcpdump auch noch der grösste Mist
>durch ;)
Vielleicht stimmt das Preable nicht. Das zeigt wireshark ja nicht mit 
an.
Auch der CRC32 wird nicht mit angezeigt.

> auf unbenutzte IOs legt das ISE
>üblicherweise ja einen pulldown (da deine link-LED blinkt ist das aber
>vmutl. nicht dein problem)
Das könnte ein Problem sein. Da beim MII ein par Pins ich glaube RX4-RX7 
auf low gezogen werden müssen.

>Ich sitze z.Z. an nem kleinen core, der GMII und MII kann, bin nur
>gerade am neu strukturieren. Sobald der wieder tut was er soll können
>wir ja mal txd/en von den Simulationen vergleichen.
Genau so etwas wollte ich auch bauen.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich kenn PHY vom 601 nicht,
Marvell 88E1111


> Probier mal, die nibble von pre7 zu swappen, also x"d5" statt x"5d".
Das ist es. Ich sehe die Datenpakete im Wireshark.
Ich hatte schon den Vektor gespiegelt und aderes, doch das High und Low 
nibble hatte ich noch nicht getauscht. Oh mann.

Jetzt läuft es!!



Das ist es. Ich sehe die Datenpakete im Wireshark.
Warum muss ich die Daten drehen?

Die Daten des  Paktets kommen unverdreht durch.

Ich habe mir extra eine Realtek-Gbit 8169 für den Test besorgt.

 rxclk für den Takt zu nutzen ist eigentlich genial, das muss ich mir 
nochmal durchdenken und sehen was der Fitter dazusagt.

Hast du noch einen Trick für die Erkennung GMII und MII?
Ich weiss nur das ich die Info aus dem seriellen Interface auslesen 
kann. Oder gibt es ein Pin an der Phy?

Autor: hunz (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich hab nen Trick für die (G)MII Erkennung ohne MDIO :-)

Im MII-Mode laufen RxClk und TxClk mit 25MHz, GTxClk wird nicht genutzt.
Im GMII-Mode läuft RxClk mit 125MHz, GTxClk kommt vom MAC und TxClk wird 
nicht genutzt.

TxClk ist im GMII-Mode entweder ganz aus, oder weiterhin 25MHz. Ich weiß 
jetzt nicht mehr, wo ich das gelesen habe und ob das so in der Spec 
steht, aber zumindes bei meinem PHY (ebenfalls der Marvell 88E1111 auf 
nem Digilent Atlys) trifft das zu.

Mein Trick ist jetzt, RxClk und TxClk zu vergleichen indem ich Ping-Pong 
zwischen den Taktdomänen spiele und gucke wie schnell der Pong aus der 
TxClk-Domäne zurückkommt.
Wenns zu lange dauert, ists GMII weil TxClk zu langsam ist, ansonsten 
ists MII-mode.

Kostet auch nur 6 LUTs im Spartan6 der Spaß :-)

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hunz schrieb:
> Ja, ich hab nen Trick für die (G)MII Erkennung ohne MDIO :-)
>
> Im MII-Mode laufen RxClk und TxClk mit 25MHz, GTxClk wird nicht genutzt.
> Im GMII-Mode läuft RxClk mit 125MHz, GTxClk kommt vom MAC und TxClk wird
> nicht genutzt.
>
> TxClk ist im GMII-Mode entweder ganz aus, oder weiterhin 25MHz. Ich weiß
> jetzt nicht mehr, wo ich das gelesen habe und ob das so in der Spec
> steht, aber zumindes bei meinem PHY (ebenfalls der Marvell 88E1111 auf
> nem Digilent Atlys) trifft das zu.
>
> Mein Trick ist jetzt, RxClk und TxClk zu vergleichen indem ich Ping-Pong
> zwischen den Taktdomänen spiele und gucke wie schnell der Pong aus der
> TxClk-Domäne zurückkommt.
> Wenns zu lange dauert, ists GMII weil TxClk zu langsam ist, ansonsten
> ists MII-mode.
>
> Kostet auch nur 6 LUTs im Spartan6 der Spaß :-)

Ich habe auch schon an so etwas gedacht, RxClk mit einer 125Mhz zu 
vergleichen, da RxClk die aktuelle Taktfrequenz annimmt.

Ich hätte eine Phasendetektor genommen und dann gemittelt.


Rxclk und Txclk in den Phasendetektor zu geben ist auch eine Variante.

Baust du nur Duplex oder auch Halfduplex mit ein?
Ich meine die ganze Kollisionsbehandlung. Es sind keine Hubs praktisch 
mehr im Handel. Sicher die Norm fordert auch die Behandlung.

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur Vollduplex. Habe selber keinen Hub mehr im Einsatz und Ziel des 
Ganzen ist ein möglichst kleiner Core mit möglichst gutem Durchsatz. 
Soll auch nicht in einem Produkt landen, daher brauche ich nicht die 
ganze Norm.

Autor: Dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hunz

Wie kannst du den Link Zustand feststellen?

Ich wollte den Carrier abfragen. Im Vollduplex ist er immer low. Ich 
hatte gehofft, dass bei gezogenem Kabel  das Signal auf High geht. Quasi 
ein busy Signal der Phy.

Leider ist es nicht so.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es wäre vielleicht schön wenn Du noch dazu schreiben könntest welchen 
FPGA Du verwendest.

Benutzt Du ein Evaluation Board oder hast Du ein eigenes Board erstellt? 
Falls Du ein eigenes Board erstellt hast würde ich erst die Hardware 
prüfen, dies kann man sich ersparen wenn man ein Evaluation Board von 
Xilinx kauft.

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dose: Ob ein Link besteht, oder nicht, werte ich bisher nicht aus. Sehe 
auch keine einfache Möglichkeit, das ohne MDIO zu erkennen.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tag zusammen!

Habe auch ein SP601 board hier, werde den code am Wochenende 
ausprobieren! Sehr interessant, habe mir aehnliches auch als naechstes 
Projekt rausgesucht.

@hunz: Es wird nicht zufaellig ein SDR?

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jan: Ich will mir zwar noch ein SDR-Zusatzboard für das Atlys machen, 
aber dafür gäbe es auch schon einen fertigen GMII-core in den USRP2 
sourcen.

Der eigene core eigentlich nur deshalb, weil die von opencores recht 
komplex waren und ich ein möglichst einfaches Interface will, dass ich 
den core auch einfach ohne richtigen Bus z.B. an einem AX8 core 
betreiben kann.

Ausserdem will ich mal milkymist auf dem Atlys laufen lassen, der 
milkymist-MAC kann aber nur MII und kein GMII.

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hunz Klingt interessant, ich habe wie gesagt das SP601 hier um erstmal 
HDL zu lernen sowie digitale Filter, Interfaces etc.. Ein Kollege macht 
die Hardware basierend auf einem Mars MX1 von Enclustra. Die sources vom 
USRP2 habe ich auch schon gesucht, nur leider nicht gefunden, viel in C 
aber nichts in VHDL... bin da irgendwie zu bloed... Idealerweise soll 
unser SDR mit GNURadio kompatibel sein, da waeren die sourcen ganz 
nuetzlich... Hast Du zufaellig einen link da? Danke!

Jan

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hunz Vielen Dank! Da hab ich jetzt erstmal was zum lesen und 
verstehen... Wirklich dumm dass es Verilog ist, aber um die Struktur zu 
verstehen solls reichen hoffe ich...

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Es wäre vielleicht schön wenn Du noch dazu schreiben könntest welchen
> FPGA Du verwendest.
>
> Benutzt Du ein Evaluation Board oder hast Du ein eigenes Board erstellt?
> Falls Du ein eigenes Board erstellt hast würde ich erst die Hardware
> prüfen, dies kann man sich ersparen wenn man ein Evaluation Board von
> Xilinx kauft.

Ich habe das SP601. Persönlich finde ich das Board nicht sehr geeignet. 
Es fehlt an einfachen Schnittstellen. Einen  Connector der nicht von 
Hand gelötet werden kann usw. Ich hoffe es gibt bald geeigneter Bretter 
mit mehr Nutzwert.

Ein SDR wollte ich auch mal bauen, ich habe es doch erst einmal weiter 
nach hinten verschoben.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich fand das SP601 zunächst auch blöd, aber mittlerweile gibts jede 
Menge FMC Karten, da ergibt die Sache schon sehr viel mehr Sinn. Und mit 
der FMC Debug Card kann man auch an die 2,54mm Anschlüsse gehen.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist denn für 1GBit Ethernet nicht der Spartan 6 zu langsam. So viel ich 
in Erinnerung habe benötigt man 125MHz Leitung für die Datenübertragung.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Ist denn für 1GBit Ethernet nicht der Spartan 6 zu langsam. So viel ich
> in Erinnerung habe benötigt man 125MHz Leitung für die Datenübertragung.

Das geht mit dem Spartan 6.

Hunz schrieb:
>@Dose: Ob ein Link besteht, oder nicht, werte ich bisher nicht aus. Sehe
>auch keine einfache Möglichkeit, das ohne MDIO zu erkennen.

Die Phys sind so schlau, die MII-Phys haben auch schon diese 
Möglichkeiten, doch die einfachsten Infos muss man aus so einem 
Seriellen Signal entlocken.

Autor: hunz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Ist denn für 1GBit Ethernet nicht der Spartan 6 zu langsam. So viel ich
> in Erinnerung habe benötigt man 125MHz Leitung für die Datenübertragung.

Das geht sogar noch mit einem Spartan-3: 
http://www.xilinx.com/products/ipcenter/TEMAC.htm

Mein TX-Pfad kommt auch bei 3E noch über 125MHz. Rx hab ich noch nicht 
getestet, sehe da aber auch nicht so das Problem. Die Kombinatorik ist 
ja nicht so komplex und IOB register helfen auch: 
http://forums.xilinx.com/t5/Virtex-Family-FPGAs/Wh... 
(gibts auch bei Spartan)
Daten kommen bei mir auch direkt aus nem BRAM, muxer dahinter für 
sfd/preamble/crc kostet auch nicht viel Laufzeit, CRC und FSM müssen 
halt schnell genug sein.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jan schrieb:
> @hunz Klingt interessant, ich habe wie gesagt das SP601 hier um erstmal
> HDL zu lernen sowie digitale Filter, Interfaces etc.. Ein Kollege macht
> die Hardware basierend auf einem Mars MX1 von Enclustra. Die sources vom
> USRP2 habe ich auch schon gesucht, nur leider nicht gefunden, viel in C
> aber nichts in VHDL... bin da irgendwie zu bloed... Idealerweise soll
> unser SDR mit GNURadio kompatibel sein, da waeren die sourcen ganz
> nuetzlich... Hast Du zufaellig einen link da? Danke!
>
> Jan

Es klingt interessant euer SDR-Vorhaben.
Kannst du mir auch ein paar Infos zukommen.
Ich bin im Forum angemeldet.

Autor: Jan K. (drj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hunz So, war am Wochenende fern des Internets, darum jetzt erst meine 
Antwort: Unser SDR ist noch gaaaanz am Anfang der Planungsphase und ich 
lerne auch erst VHDL (abends und nebenbei...), die software wird dann 
sicher open-source sein, bei der hardware bin ich mir da nicht sicher, 
die macht jemand anderes des evtl. den einen oder anderen SDR auch gerne 
verkaufen moechte... Kannst Dich ja nochmal melden wenn noch interesse 
besteht, bin noch angemeldet. Wichtigstes Ziel bei unserem  SDR ist 
uebrigens mind. 10MHz Bandbreite bzw. Banduebersicht und wenn moeglich 
auch diese 10Mhz als I/Q Daten an den PC zu schicken, dann koennte man 
damit auch (digital) fernsehen :-)

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hört sich alles sehr interessant an. Ich werde mir auch mal das 
SP601 zulegen. Dies gibt es bei Digikey ja schon für 278$ zu kaufen was 
ja recht günstig ist.

Ich habe bereits schon mal so gut es geht mit Infos vollgestopft. Hierzu 
habe ich das Datenblatt vom Marvell PHY 88E1111 durchgelesen. Hierbei 
ist mir aufgefallen das keine Timings für die GMII oder andere MAC 
Schnittstellen beschrieben sind. Außerdem fehlt die Information über die 
komplette Konfiguration der internen Konfigurationsregister.

Gibt es von Marvell ein zusätzliches Datenlatt? Ich habe mal das 
Datenblatt vom National Nationa PHY DP83865 heruntergeladen dort stehen 
deutlich mehr Infos drin.


Nun zu dem was ich Umsetzen möchte:

1. Ich möchte Daten digitalisieren und in Richtung PC übertragen. Das 
ganze wird direkt ohne Router dazwischen an den PC (GBIT Anschluss des 
Mainboards) angeschlossen. Demnach muss ich die GMII oder RGMII Mac 
Interface benutzen. Welches ist dafür denn besser geeignet? Wie kann ich 
denn dem Marvel Chip sagen welches Interface verwendet werden soll?

2. Welches Interface ist denn als Default eingestellt?

3. Welches Protokoll sollte man denn dafür am besten verwenden TCP oder 
UDP oder Peer to Peer?

4. Habt Ihr einige Links wo gut erklährt wird wie das MAC Protokoll 
aufgekaubt ist?

5. Wie hoch ist denn die Maximal zu erreichende Datenrate bei den 
größten Frames? Schaffe ich da 100MByte pro Sekunde?

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gegen NDA gibts von Marvell ein personalisiertes vollständiges 
Datenblatt.

100MB/s erreicht man meiner Erfahrung nach höchstens mit UDP. Wir hatten 
sowas mal als Diplomarbeit mit dem ML403 Board hier laufen. Da konnten 
wir mit etwas über 100MB/s Daten aus dem SDRAM über UDP zum PC streamen. 
Allerdings nur mit riesen Puffern im MAC, CheckSum Offloading in 
Hardware und massivem Einsatz des MPMC DMA Controllers im Scatter-Gather 
Modus zum Zusammenbauen der Pakete. Allerdings war der Virtex 4 dann so 
voll, dass im Prinzip keine User-Logic mehr reingepasst hat. Die ganze 
Geschichte haben wir dann zu Gunsten von external PCI Express erst mal 
auf Eis gelegt. Mit PCIe erreicht man selbst mit x1 schon 166MB/s über 
eine One-Chip Lösung ohne Verrenkungen und über Kabel geht das ganz 
vorzüglich.

Autor: Dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Das hört sich alles sehr interessant an. Ich werde mir auch mal das
> SP601 zulegen. Dies gibt es bei Digikey ja schon für 278$ zu kaufen was
> ja recht günstig ist.

Ich habe mein Board von Trenz electronic.

100MByte sind schaffbar, doch so schnell kann keiner die Daten 
weiterverarbeiten. Bei deinem PC wird der Ethernet-Fifo überlaufen oder 
willst du zwischen zwei FPGAs Ethernet als High Speed Leitung betreiben?

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Über die Verarbeitung auf PC Seite mache ich mir jetzt keine Sorgen, das 
ist schon alles gelöst.

Die Frage ist halt welches Protokoll ich für solche Ethernetübertragung 
verwende. Ich bin noch am überlegen ob ich TCP oder UDP verwende, oder 
ob es mit noch weniger Overhead geht.

Gibt es vielleicht auch Netzwerdirektverbinden ohne dem IP-Protokoll?

@ Christian R.
Ich weis das man dies auch mit PCIe 1x lösen kann jedoch suche ich etwas 
sehr kostengünstiges und was auch an ein Notebook geht. Ein modernes 
Notebook besitzt eine GBit Ethernet Schnittstelle und diese möchte ich 
auch gerne verwenden.

Im optimalen Fall muss ja 125MByte über diese Leitung gehen, zieht man 
dann den Overhead ab dann sollten noch 100MByte machbar sein (kommt 
natürlich auf die Größe der Frames an). Jedoch ist es möglich doch heute 
Jumbo Frames zu verwenden

Auf dem SDK Board von Xilinx ist doch ein 128MByte großer Speicher drauf 
diese sollte doch ausreichen groß sein (als Ausgabebuffer).

Ich habe eine Zeilenkamera gekauft, die hat einen GBit Ethernet 
Anschluss und die Kamera erzeugt einen Datenstrom von ca. 102MByte pro 
Sekunde, demnach mus es ja möglich sein ^^

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, du kannst auf einem Laptop einen 100MByte/s Datenstrom in Echtzeit 
verarbeiten? Oder werden die Daten nur visualisiert? Für sowas sollte 
UDP schon das richtige sein, die Kameras arbeiten ja auch alle mit UDP. 
Auf ein paar fehlende Pakete, wenn der PC nicht hinterher kommt, kommts 
ja da nicht an.

Autor: rev (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian R. schrieb:
> 00MB/s erreicht man meiner Erfahrung nach höchstens mit UDP. Wir hatten
> sowas mal als Diplomarbeit mit dem ML403 Board hier laufen. Da konnten
> wir mit etwas über 100MB/s Daten aus dem SDRAM über UDP zum PC streamen.
> Allerdings nur mit riesen Puffern im MAC, CheckSum Offloading in
> Hardware und massivem Einsatz des MPMC DMA Controllers im Scatter-Gather
> Modus zum Zusammenbauen der Pakete. Allerdings war der Virtex 4 dann so
> voll, dass im Prinzip keine User-Logic mehr reingepasst hat.

Wir haben in Board mit V4FX40 auf Basis des ML403. Mit dem MPMC-DMA und 
CS-Offload bekomme ich mit dem PowerPC unter Linux volle 100Mbit auf 
TCP/IP (!) hin.
Xilinx hat da inzwischen ziemlich viele Appnotes.

Autor: Dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rev schrieb:
> dem PowerPC unter Linux volle 100Mbit auf
> TCP/IP (!) hin.
Das ist auch normal

es ging um 100MByt, das ist das achtfache.



>Johann (Gast)
>Ich habe eine Zeilenkamera gekauft, die hat einen GBit Ethernet
>Anschluss und die Kamera erzeugt einen Datenstrom von ca. 102MByte pro
>Sekunde, demnach mus es ja möglich sein ^^

Dann musst du doch das Protokoll kennen. Ansonsten mit wireshark 
mitscheiden.  Das wäre schon mal interessant.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das könnte ich machen. Ich stelle auf der Kamera ein Testbild ein das 
ist dann konstant und somit könnte ich das mal mitschneiden.

Ich verwende Labview als Software und dort kann man UDP und TCP/IP ganz 
leicht implementieren jedoch kamen nie Daten rein deshalb war ich halt 
immer skeptisch ob die Kameras nicht ein anderes Protokoll verwenden.


@ Christian
100MBit zu 1000MBit ist das zehnfache :-)
Wie machen 2D Bilder im medizintechnischen Bereich deshalb wäre es 
natürlich nicht so schön wenn Daten verloren gehen. Jedoch wenn man gut 
geschirmte Kat 6 Kabel kauft, die Leitung kurz ist und die Timings 
eingehalten werden sollte keine Fehler auftreten so das UPD ausreicht, 
zudem besitzt UDP ja noch eine Vorwärtskorrektur, so das eventuell 
auftretende Fehler vom Empfänger behoben werden können und somit das 
Datenpaket nicht erneut gesendet werden muss


Ich habe mir einige UDP Sender in VDHL angeschaut und o versucht das 
Protokoll zu verstehen

1. Gibt es einige lesenswerte Internetseiten oder PDFs wo das IP/UDP 
Protokoll gut beschrieben wird?

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für FFTs und andere Berechnungen verwende ich gerne die GPU als 
Co-Prozessor dies ist deutlich schneller als die CPU. Auf einem Desktop 
PC (4Kerne Intel I7 920) habe ich 100 mal länger für die Berechnung 
benötigt als auf der Grafikkarte.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> @ Christian
> 100MBit zu 1000MBit ist das zehnfache :-)

Ich hab das gar nicht geschrieben mit Faktor 8. 100MByte/s zu 100MBit/s 
wären allerdings 8. Darauf bezog sich das weiter oben.

> Wie machen 2D Bilder im medizintechnischen Bereich deshalb wäre es
> natürlich nicht so schön wenn Daten verloren gehen. Jedoch wenn man gut
> geschirmte Kat 6 Kabel kauft, die Leitung kurz ist und die Timings
> eingehalten werden sollte keine Fehler auftreten so das UPD ausreicht,
> zudem besitzt UDP ja noch eine Vorwärtskorrektur, so das eventuell
> auftretende Fehler vom Empfänger behoben werden können und somit das
> Datenpaket nicht erneut gesendet werden muss

Naja, da bin ich skeptisch. Wir hatten das bei der Diplomarbeit hier, 
dass der PC dann förmlich überfahren wurde mit Datenstrom, und dann 
Pakete massenhaft weggekommen waren. Du hast ja keine Flusskontrolle. 
FEC bringt da nicht viel, wenn Puffer voll, dann voll. Und wo speicherst 
du einen konstanten 100MB/s Datenstrom? Wenn alle Frames gefordert 
sind, und nix verloren gehen darf, würde ich nochmal das Konzept 
überdenken. Wir machen Ultraschall-Prüftechnik, da darf kein einziges 
Byte verloren gehen. Deswegen arbeiten wir mit USB 2.0 und PCIe 
external.

Autor: rev (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dose schrieb:
>> dem PowerPC unter Linux volle 100Mbit auf
>> TCP/IP (!) hin.
> Das ist auch normal
>
> es ging um 100MByt, das ist das achtfache.

Ups, verlesen :)
100MByte/s ist natürlich sportlich auf dem Virtex-4

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rev schrieb:
> 100MByte/s ist natürlich sportlich auf dem Virtex-4

Naja, andererseits erwartet man das aber auch von einem Hard-TEMAC mit 
soviel HW-Unterstützung, DMA und dem schnellen PPC. Mit dem Xilinx Stack 
allerdings völlig utopisch, auch der LwIP bringt nicht viel. Da musste 
der Diplomand viel selbst schreiben.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist doch auch ein Spartan 6 :-)

So wie ich es überschaue ist es doch nicht sol schlimm. Ich will die 
ganzen IP und MAC Konfiguration in einen ROM (BlockRAM) packen. Dann 
muss ich mit 1 Multiplexer nur zwischen den Header und den Daten 
schalten und das halt mit 125MHz. Falls der Spartan 6 zu langsam ist 
bleibt ja immerhin noch der Virtex 5 :-))

Ich suche halt noch gutes Material zum lesen wie die Pakete aufgebaut 
sein müssen ich konnte zwar schon viel aus den Beispielen erkennen doch 
würde ich es gerne noch mal als Text lesen.

In den Beispielen verwenden alle ja immer die Statemachine mit 57 
Zustaänden das dies dann nicht mehr die Performance hat sollte doch 
jedem klar sein. Das wird ja ein ganzer Wald von Multiplexern die alle 
durchlaufen werden müssen und somit keine hoche Laufzeit mehr möglich 
ist.

Aber wir alten hasen machen es doch besser :-))

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Christian R.

Wir haben die Kamera ausprobiert und es gehen keine Daten verloren. Ich 
habe die Kamera auf Testbild gestellt und dann das Graukeil automatisch 
auf Fehler überprüft es geht sehr gut.

Demnach muss es gehen. Wir haben eine Kamera von der Firma E2V gekauft 
(gibt es im Shop von der Firma Rauscher zu kaufen).

Autor: LAN_Finder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rene hat ja schon ganz gut vorgelegt. Sehr gut überlegter Aufbau des 
Senders. Nicht so wie alle anderen bisher geposteten Schnellschüsse. 
Bugs sind in dem Status normal.


> Ich suche halt noch gutes Material zum lesen wie die Pakete aufgebaut
> sein müssen ich konnte zwar schon viel aus den Beispielen erkennen doch
> würde ich es gerne noch mal als Text lesen.
Die Literaturreferenz wäre für das Forum sehr interessant.

>Gibt es einige lesenswerte Internetseiten oder PDFs wo das IP/UDP
>Protokoll gut beschrieben wird?

UDP ist noch nicht das Ende des Datenaustausches. UDP ist eine 
Verbindungsart. Darauf läuft noch ein Dienst. Telnet, FTP, HTTP oder 
ähnliches. Es sind auch die höheren Schichten des OSI Modelles zu 
realisieren.

> In den Beispielen verwenden alle ja immer die Statemachine mit 57
> Zustaänden das dies dann nicht mehr die Performance hat sollte doch
> jedem klar sein. Das wird ja ein ganzer Wald von Multiplexern die alle
> durchlaufen werden müssen und somit keine hoche Laufzeit mehr möglich
> ist.
>
> Aber wir alten hasen machen es doch besser :-))

Ich weiss nicht was du mit den 57 Zuständen meinst.


Hat schon weiter am Code weiter gearbeitet? Es scheint interessant zu 
werden.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe nicht den Code von Rene gemeint sondern den UDP100 Sender aus 
einem anderen Post.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
LAN_Finder schrieb:

> Hat jemand schon am Code weiter gearbeitet? Es scheint interessant
> zu werden.

Ja ich habe etwas weitergearbeitet. Mittlerweile kann ich auch 
empfangen. Ich überlege noch, wie ich die Schnittstelle für den Empfang 
ideal baue. Erst alles im FIFO puffern und den CRC kontrollieren. Wie 
reiche ich die Daten schnell weiter ohne, dass der Puffer überläuft?
Wie weit gehe ich mit VHDL und ab welcher Übertragungsschicht nutze ich 
einen Softcore und welchen?
Da bin ich noch am überlegen. Da fällt nicht gleich alles vom Himmel. 
Ich arbeite z.Z. auch nur nebenbei daran.
Wie es werden soll habe ich schon schematisch. Bei der Umsetzung ist man 
immer am Lernen und verbessert den Entwurf.

zu Johann den UTP100 kenne ich auch, ich fand ihn auch unbrauchbar. 
Darin ist keine verwendbare Schnittstelle enthalten.

zu external PCI Express
mal sehen wie lange sich der Standard hält und verfügbar ist. Eine 1000M 
fähige Ethernetkarte wird es noch lange zu einem vernünftigen Preis 
geben. Und auch die maximal Länge ist sicher bei E-PCI sehr beschränkt.

Interessant sind die Anwendungen die schon erwähnt wurden.
Bildbearbeitung, Ultraschall, SDR
Ich habe in allen Richtungen schon mal etwas mit VHDL gearbeitet. Da 
hätte ich auch wieder Lust einzusteigen.
Der GMII ist aus der Not entstanden, da es die interessanteste 
Schnittstelle auf dem SP601 ist.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bis jetzt habe ich noch keine brauchbare zusammenhängie Literatur 
gefunden die das Ethernet Protokoll mit UDP sauber beschreibt, alles was 
ich bis jetzt gefunden habe wirft halt sehr viele Fragen auf.

Für mich ist zuerst nur der Sender sehr interessant den schweren Teil 
uns zwar den Empfänger hebe ich mir immer bis zum Schluss auf :-)

Ich habe halte die vorhandenen Codebeispile versucht zu verstehen.

Das größte Verständnisproblem habe ich allerdings mit dem Framaufbau. So 
viel ich bis jetzt mitbekommen habe unterstützen die Netzwerkchip (die 
im PC verhanden sind) nur Frames mit kleiner 1500Bytes pro Frame. Es 
gibt auch schon Karten mit dem Jumboframes aber da scheinen oft Probleme 
mit den Treibern oder anderen Dingen aufzutreten.


Ich stelle mir das ja immer wie folgt vor. Ich habe eine Digitalisierung 
die erzeugt einen unendlich lange Datenstrom. Diesen möchte ich jetzt an 
den PC übertragen. Die Daten schreibe ich in einem FIFO wenn mehr als 
1500Bytes im FIFO vorhanden sind dann will ich eine Datenübertragung 
starten also ein Frame erzeugen. Demnach muss ich während der 
Digitaliserung am besten CRC32 berechnen.

Ich muss die Daten zuerst mit dem UDP Header versehen anschließen kommt 
das IP Header und zuletzt der Ethernet Header, jedoch habe ich bis jetzt 
keine wirklich gute Dokumentation und vor allem Beispiele von den 
Headern gefunden.

Wenn ich jetzt das Frame mit dem 1500Bytes an Daten übertragen habe 
warte ich wieder bis 1500 neue Bytes im FIFO sind. Jedoch ist mir nicht 
ganz klar wozu man diese Framenummerierung benötigt wenn man größere 
Datenmengen übertragen will..

Autor: T. M. (xgcfx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So oder ähnlich würde ich auch vorgehen. Du müsstest nur schon bei etwas 
weniger als 1500 Byte Payload das Paket zusammenbasteln, weil da ja noch 
einiges an Headern dazukommt.

Die Beschreibungen für TCP/IP/UDP/Ethernet dürftest du in den RFC's, 
(zB. hier: http://www.faqs.org/rfcs/) finden.

Anhand der Framenummerierung können fragmentierte Pakete wieder korrekt 
zusammengesetzt werden. Außerdem könnte die auch noch relevant sein, 
wenn man Streaming mit UDP macht, indem man alte Pakete mit alten 
Nummern dann einfach verwirft, weil die eh nicht mehr benötigt werden.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Bis jetzt habe ich noch keine brauchbare zusammenhängie Literatur
> gefunden die das Ethernet Protokoll mit UDP sauber beschreibt, alles was
> ich bis jetzt gefunden habe wirft halt sehr viele Fragen auf.
>
> Für mich ist zuerst nur der Sender sehr interessant den schweren Teil
> uns zwar den Empfänger hebe ich mir immer bis zum Schluss auf :-)
>
> Ich habe halte die vorhandenen Codebeispile versucht zu verstehen.
>
> Das größte Verständnisproblem habe ich allerdings mit dem Framaufbau. So
> viel ich bis jetzt mitbekommen habe unterstützen die Netzwerkchip (die
> im PC verhanden sind) nur Frames mit kleiner 1500Bytes pro Frame.

Die Marvell PHY unterstützt Jumbo-Frames. Doch die wollte ich erst im 
zweiten Schritt angehen.


> gibt auch schon Karten mit dem Jumboframes aber da scheinen oft Probleme
> mit den Treibern oder anderen Dingen aufzutreten.
Keine Ahnung wo die Flaschenhälse bei Jumboframes momentan sind.
Die Nutzdatenmenge ist auch bei kleinen Paketen noch sehr groß.


> Ich stelle mir das ja immer wie folgt vor. Ich habe eine Digitalisierung
> die erzeugt einen unendlich lange Datenstrom. Diesen möchte ich jetzt an
> den PC übertragen. Die Daten schreibe ich in einem FIFO wenn mehr als
> 1500Bytes im FIFO vorhanden sind dann will ich eine Datenübertragung
> starten also ein Frame erzeugen. Demnach muss ich während der
> Digitaliserung am besten CRC32 berechnen.

CRC32 gleich parallel zum Datenstrom zu berechnen, ist bereits getütet
No Problem

> Ich muss die Daten zuerst mit dem UDP Header versehen anschließen kommt
> das IP Header und zuletzt der Ethernet Header, jedoch habe ich bis jetzt
> keine wirklich gute Dokumentation und vor allem Beispiele von den
> Headern gefunden.
Das habe ich mir bereits auch angeschaut und verstanden. Sicher ein 
ordentliches Papier wäre nicht schlecht. Die RFCs sind sehr trocken und 
lesen sich wie ein Lexikon.

> Wenn ich jetzt das Frame mit dem 1500Bytes an Daten übertragen habe
> warte ich wieder bis 1500 neue Bytes im FIFO sind. Jedoch ist mir nicht
> ganz klar wozu man diese Framenummerierung benötigt wenn man größere
> Datenmengen übertragen will..

So will ich es auch machen. Nur mit dem Unterschied der PC sendet ein 
ACK, dass er auch wieder bereit ist. Dann geht das nächste Paket wieder 
raus.
Als Flusskontrolle, sonst läuft der FiFo im PC über. Irgend so eine 
Flusskontrolle muss auch deine Zeilenkamera benutzen. Deshalb solltest 
du mal mit wireshark mitschneiden!!!



Es sind noch weitere Protokolle Pflichtprogramm, damit die 
Netzwerkteilnehmer sich finden.
Das habe ich auch schon durchgeforstet.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Von welchen Protokollen redest Du denn jetzet dieser Autonegration oder 
wie auch immer dies heist, das man wenn man im IDLE ist immer in 
regelmäßigen Abständen Pulse sendet

@ Rene

Hast Du denn keine Links oder Buchtips? Immerhind hast Du bereits ja 
eine Datenübertragung hinbekommen.

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> Von welchen Protokollen redest Du denn jetzet dieser Autonegration oder
> wie auch immer dies heist, das man wenn man im IDLE ist immer in
> regelmäßigen Abständen Pulse sendet

Nein. Die Routingtabellen müssen vor dem Verbinden aktualisiert werden.
Wie wäre es mit Ping.

>
> @ Rene
>
> Hast Du denn keine Links oder Buchtips? Immerhind hast Du bereits ja
> eine Datenübertragung hinbekommen.

Ich habe die unterste Übertragungsschicht hinbekommen. Die Höheren 
Ebenen fehlen noch ISO OSI Referenz Modell anschauen.

Ich hatte eine Diplomarbeit, die hat solche Sachen erklärt.
Und jetzt mein Problem. Ein Praktikant hat diese entführt und ist 
verschwunden. Ich arbeite aus dem Gedächtnis und bei Problemen fällt mir 
nach einer gewissen Zeit dann doch wieder ein Schlagwort ein, da ich die 
Diplomarbeit gelesen habe.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habt Ihr denn keine PDF Version davon?

Ping ist bei Mir nicht von Interesse ich will erst nur mal Daten senden.

Autor: Johann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Rene die CRC Berechnung bei Dir ist mir zu hoch :-)

So ein For schleife habe ich noch nie eingesetzt beim VHDL Code was wird 
denn daraus erzeugt?

Ich dachte immer CRC werden mt der vielen XOR erzeugt.

Was hat das mit der Arrayfunktion bei Dir im Quellcode auf ist das ein 
normaler Block RAM oder ist das RAM aus Logic Elementen?

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Johann schrieb:
> @ Rene die CRC Berechnung bei Dir ist mir zu hoch :-)
>
> So ein For schleife habe ich noch nie eingesetzt beim VHDL Code was wird
> denn daraus erzeugt?
>
> Ich dachte immer CRC werden mt der vielen XOR erzeugt.

Bei CRC werden die Daten bitweise "eingeschoben". Da der Datenbus 8 bit 
breit ist, würde die Berechnung 8 Takte benötigen. Da gibt es 
verschiedene mathematische Lösungen. Logische Verknüpfungen,Tabellen 
oder andere Lösungswege.

> Was hat das mit der Arrayfunktion bei Dir im Quellcode auf ist das ein
> normaler Block RAM oder ist das RAM aus Logic Elementen?

Blockram

Ich habe eine andere Frage was sind das für Blöcke, die im meinem Design 
auftauchen?

Senden geht auch schon im MII Modus.

Autor: MLG (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René D. schrieb:
> Senden geht auch schon im MII Modus.

und GMII?

Autor: René D. (Firma: www.dossmatik.de) (dose)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MLG schrieb:
> René D. schrieb:
>> Senden geht auch schon im MII Modus.
>
> und GMII?

Ja GMII geht auch das war ja das Hauptanliegen.


Das schlechte an GMII ist, wenn die Verbindung nur 100Mbit ist. Dann 
kann man die Daten nur im MII übergeben.

GMII ist 8bit breit und MII ist 4 bit breit.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.