Hi, ich probiere gerade einen Ethernetcontroller zu basteln, wenn möglich einen Gigabit-Ethernetcontroller. Ich befasse mich gerade mit der GMII-Schnittstelle der ersten beiden Layer (PHY <-> MAC). Wie viele hier im Forum verwende ich den Marvell PHY 88e111. Ausgangsbasis meines Codes ist der Beispiel Code des 10MBit-Ethernetcontroller von FPGA4fun.com. Kurz zu meinen Vorkenntnissen: ich hab in meinem Studium 1-2 Sachen mit FPGAs gemacht und mich mit den theoretischen Grundlagen des logischen Entwurf von digitalen System auseinandergesetzt, würde mich aber trotzdem als Noob/Anfänger bezeichnen. Hardwarebasis meines Projekts ist ein SP601 Xilinx Evaluation KIT wo ein Spartan6 und der PHY integriert sind. Mein Hauptproblem ist, dass es so gut wie keine Informationen über den Marvell 88e1111 finde. Ich habe bereits gelesen, dass man dazu einen NDA (oder ähnliches) benötigt. Da aber im Handbuch des Evaluations Kits steht, dass der PHY standardmässig im GMII-Modus läuft (festverdrahtete Konfigurationspins) und es ja einen gewissen Protokollstandard für GMII gibt, dachte ich, dass ich mein Projekt vielleicht auch ohne NDA, etc realisieren kann. Den PHY per reset-pin zu aktivieren funktioniert, meine TX-LED leuchtet ebenfalls, aber auf meinen Empfangs-PC lässt sich mit Wireshark nichts entdecken was auf meine gesendeten Daten hinweißt. Außer vom PC gesendete Broadcast- und ARP-Daten-wirrwarr (am Anfang bzw. bei jedem Reset) ist da nichts zu sehen. Da ich mich jetzt seit fast 2,5 Wochen mit dem Projekt befasse, habe ich verschiedenste Konfigurationen (MSB/LSB wechseln der Daten-Pakete)und verschiedenste Formen der CRC32-Berechnung (MSB/LSB-Wechsel der Eingangs- und Ausgangsdaten, Invertierung der Ausgangsdaten des CRC-Registers, etc)ausprobiert. Für die CRC32-Berechnung verwendet ich zur Zeit ein Template aus dem Netz. Auch verschiedene Clock-Frequenzen (125 MHZ und 25 Mhz) brachten keine Veränderung. Ebenfalls Veränderungen des Ethernet-Headers (beispielsweise SFD-Byte 5D -> D5 Wechsel), haben mich nicht weitergebracht. Als letztes hab ich nun versucht das TX-Error-Signal gleichzeitig mit dem TX-Enable-Signale zu aktivieren und den PHY somit zu zwingen meine Daten (auch wenn fehlerhaft) auf die Datenleitung zu legen.... kein Erfolg, kommt nix am PC bzw Wireshark an. Meine Vermutung ist das irgendwas mit der Paketzusammenstellung nicht stimmt. Der 10Mbit-Controller von FPGA4Fun hab ich zwar zum laufen gebracht, aber ich weiß halt nicht genau, welche Daten eines Ethernetframes und speziell in welcher Form (MSB oder LSB voran, etc) der PHY von meinem Controller benötigt. Um die Dinge wie Pausen-Frames oder Gap-Frames hab ich mich bisher nicht gekümmtert, da ich meine Pakete bei maximal Frequenz(125 MHz) in Abständen von mehr als 0,3 Sekunden verschickt habe und somit keine kritischen Zeitabstände gewählt habe. Bei 25 Mhz schicke ich zur Zeit etwa alle 1,5 -2 Sekunden ein Paket. (Gesamtframe ist zur Zeit 72 byte lang, also größer als die geforderten 64 byte) Bevor ich mich nun mit der MDIO-Schnittstelle befasse und da nach einer Lösung suche, wollte ich einfach mal gucken ob hier jmd vielleicht einen Fehler entdeckt, denn ich die ganze Zeit übersehe. Vielen Dank an alle die sich Zeit nehmen Grüße Ps. habe meinen Code und den Code der CRC32-Berechnungn angehängt ich hoffe er ist lesbar und verständlich genung kommentiert. Hab verschiedene Testsignale und Testbuttons eingefügt, die einfach ignorieren.
Das Datenblatt erhält man nur, wenn man bei Marvell einen "NDA" unterschreibt. Und ohne das Datenblatt kommt man nicht weit (z.B. weil man die korrekten Setup/Hold-Zeiten für die Signale im UCF angeben muß).
Vor genau diesem Problem am selben Boards stand ich auch schau mal hier. Beitrag "Ethernet GMII" die Nibbles sind in Preamble verdreht. Dan lief der Code.
Hab ich auch schon versucht. Das meinte ich als ich oben schrieb SFD d5->5d switch. Oder meinst du ich soll alle nibbles drehen also auch die 7 x 55 vorher?
G. A. schrieb: > aber auf meinen Empfangs-PC lässt sich mit Wireshark nichts > entdecken was auf meine gesendeten Daten hinweißt. Läuft denn Dein Wireshark im promiscous mode? Duke
Sry, hab von diesem promiscous mode gehört, aber die Einstellung dazu nicht gefunden. Könntes du kurz erklären, wo ich das einstellen kann?? Shaheed edit: hat sich erledigt, wireshark lief schon die ganze zeit in promiscous mode
Das CRC wird negiert übertragen. Die Reihenfolge der Bits könnte auch noch falsch sein. Hier der Codeschnipsel aus meinem zitierten Code. if state_txin=crc1 then fifo_ram(to_integer(waddr(addr_width-1 downto 0)))<= not crc32(7 downto 0); end if; if state_txin=crc2 then fifo_ram(to_integer(waddr(addr_width-1 downto 0)))<= not crc32(15 downto 8); end if; if state_txin=crc3 then fifo_ram(to_integer(waddr(addr_width-1 downto 0)))<= not crc32(23 downto 16); start_addr<=next_start_addr; end if; if state_txin=crc4 then fifo_ram(to_integer(waddr(addr_width-1 downto 0)))<= not crc32(31 downto 24);
Ich habe den Marvel auch ohne Datenblatt bedient. Die Standard-MDIO Register können beschreiben werden, und dann reicht z.B. das Dokument UG-194 von Xilinx ab Kapitel 5. Meinen CRC Code (VHDL) habe ich vor Monaten hier mal gepostet, müßte über die Suchfunktion zu finden sein. Der Wireshark hat Pakete nur angezeigt, wenn sie wirklich korrekt waren, also mit gültiger CRC usw. Fehlerhafte Pakete wurden ignoriert, wohl schon von dem PC-Ethernet Adapter.
Vielen Dank erstmal an alle die hier geantwortet haben. Hatte noch einen Fehler in meinem Code gefunden, hab die falsche Clock für meinen CRC-Algo benutzt, aber auch die richtige Clock hat mich leider nicht weiter gebracht. Pitty, ich benutzte nun deine CRC32-Berechnung (hoffe das ist ok :)) hab aber noch eine Frage dazu: Laut deinen Kommentaren verschickst du das CRC-Ergebnisregister negiert und auch von LSB nach MSB. Wenn ich mir jedoch deinen Code angucke, dann hast du nur die Reihenfolge der 4 Bytes umkehrt. Zum Verständnis : CRC32 (31-0) = CRC1 (31-24) | CRC2(23-16) ... |CRC4(7-0) (8-Bit) verschickst du folgendermaßen = CRC4 (7-0)| CRC3(15-8)| ... |CRC4(31-24). Aber anscheinend funktioniert es bei dir oder?? Naja wichtigste Erkenntnis ich kann den Marvell PHY auch ohne NDA zum laufen bringen und wenn die Packete nicht 100 pro stimmen dann werden sie nicht angezeigt von Wireshark. Hätte noch eine kurze Frage an Pitty hast du das MIDO-Interface benötigt um dein Modul einzusetzten oder ist auch im vorkonfigurierten Modus der PHY einsatzbereit und man kann senden und empfangen?? Gruß Shaheed
Ich habe ein paar Tage herumgespielt, bis der CRC-Code lief. So können evtl die Kommentare nicht ganz stimmen. War auch nur als Test für mich gedacht, im Projekt verwenden wir doch einen käuflichen IP-Core. Die Berechnung und das Senden funktioniert. Auf dem PC konnte ich mit Wireshark das Paket anschauen. Ich habe auch ein MDIO-Modul implementiert. Danach dann festgestellt, dass der PHY auch ohne zusätzliche Initialisierung per MDIO arbeitet. Ich habe das Interface allerdings beim Entwickeln benutzt, um Register aus dem PHY auszulesen, und so zu sehen, ob der PHY überhaupt geht. Das wichtigste war allerdings die korrekte Timing-Sequenz beim Reset. Und dann auch noch der 125MHz Takt, der um 90 Grad verschoben ist: Altera PLL-Generator: MHZ125Generator : PLL125Generator port map ( areset => '0', inclk0 => CLOCK_50, c0 => MHZ_125 , c1 => MHZ_125_90deg, locked => open ); der dann für die GTX_CLK benutzt wird ENET0_GTX_CLK <= MHZ_125_90deg;
G. A. schrieb: > Naja wichtigste Erkenntnis ich kann den Marvell PHY auch ohne NDA zum > laufen bringen und wenn die Packete nicht 100 pro stimmen dann werden > sie nicht angezeigt von Wireshark. Bei mir lief er erst nach einem Blick ins Datenblatt (siehe [1]). Die fähigsten Leute bei Xilinx hatten vergessen zu erwähnen, das der Reset low aktiv ist. Duke [1] Beitrag "Re: Digilent Atlys (mit Spartan6)."
Ich plane ebenfalls, den PHY über Altera zu bedienen. Ich habe das Cyclone4 Eval board von Terasic. Dort sind 2 davon drauf. Leider ist Altera sehr sparsam mit Infos. @Pitty: Könntest du mir einen Tipp gebeben, mit welchen Resourcen ich für einen MAC rechnen muss?
Hier die verbrauchten Resourcen für einen Single-MAC auf einem Altera Cyclone 4. Das Programm läuft auf dem DE2-115 und verschickt ein Ethernet-Paket auf 'Knopfdruck'.
So hab es erstmal hinbekommen, hab mir von verschiedensten Seiten meinen Code zusammengebastelt und jetzt klappts!! Ich werd den Code hier hochladen, damit jeder der interessiert ist oder den Marvell PHY auch verwenden will, eine kleine Einstiegshilfe hat. Er ist noch nicht ganz sauber ... vom Syntax her und man kann bestimmt auch einige Sachen geschickter regeln, aber hey ich befasse mich gerade mal 3 Wochen mit FPGAs und Verilog, wem der Code so nicht passt, kann ihn gerne verändern. Er läuft definitiv mit dem Sp601-Board und ich denke er sollte auch auf jedem anderen FPGA in Kombination mit dem Marvell PHY funktionieren (da muss dann halt die ucf-Datei angepasst werden). Bisher kann man nur selbst zusammengestellte UDP-Pakete mit einer Datenlänge biszu 76 Byte versenden. Für größere Pakete müssten ein paar Variablen angepasst werden. Ebenso muss jeder IP- und MAC -Adressen (Sender&Empfänger) im Code neukonfigurieren sonst werden die Pakete als falsch markiert. Ein paar Anmerkungen warum es jetzt klappt: Das Wichtigste ist wirklich die Synchronisation der Sendelogik mit dem gestellt Takt des PHYs, wenn das nicht stimmt --> kommt nix an!! Meine Sende/Synchronisationslogik hab ich mir größten Teils aus einem mitgelieferten Referenz-Design des SP601 zusammengebastelt. Komplett verstehen tue ich sie selbst nicht, da ich noch keine Testbenches schreiben kann und somit keine brauchbares Timingdiagramm erfassen kann. Hab versucht die entscheidenen Signal nach außen zulegen und aufm nem Ozilloskope anzugucken, aber da kann man max. 2 Signale auf einmal sehen, was nicht viel bringt. CRC darf falsch sein, werden auch von Wireshark angezeigt, aber als falsch markiert. Zum Schluss ich werde jetzt versuchen meinen Controller durch einen Empfangslogik zu erweitern, so daß man ihn als generelle Schnittstelle zwischen PHY und sonstiger Logik verwenden kann. Gruß Shaheed Ps. hoffe meine Kommentierung ist verständlich genug, wer Fragen hat mich einfach an schreiben Pss. Ach ja der Controller sollte auch Gbit fähig sein. klappt bei mir nicht da meine Ethernetkarte nur 100 Mbit unterstützt, aber laut Logik sollte es funtkionieren.
PittyJ schrieb: > Das Programm läuft auf dem DE2-115 und verschickt ein Ethernet-Paket auf > 'Knopfdruck'. Welches Cyclone 4 Board verwendet Du? Ich habe auch ein solches und wäre an einem Austausch interessiert. G. A. schrieb: > Ach ja der Controller sollte auch Gbit fähig sein. klappt bei mir > nicht da meine Ethernetkarte nur 100 Mbit unterstützt Kannst Du es nicht an einen üblichen Switch hängen? Der Controller handelt dann automatisch gegenüber dem einen Teilnehmer die Gbit-Verbindung aus. Zumindest das müsstest du sehen können. (wenn der Phy aus dem reset kommt und entsprechend parametiert wird). Wenn die Verbindung steht, müsstes du auch kommunizieren können, weil der switch gegen Deine Netzwerkkarte dann auf 100MBit übersetzt.
ich hab das sp601 dev board von Xilinx. Der Code der hier oben noch steht ist so übrigens nicht Gbit fähig. Ich musste noch ein Zeile dafür verändern. Ich weiß jetzt nicht genau was du meinst, aber je nach dem was der PHY mit der Gegenseite aushandelt (das läuft über Autonegotiation) musst du dann den PHY mit entsprechenden Daten füttern. Also entweder MII oder GMII- Interface. Ich denke es ist möglich einen Switch oder was auch immer zwischen die Verbindung zu hängen der die Pakete dann weiterleitet. Man muss dann - denke ich - nur aufpassen das der TTL-Wert im Paket (Time-to-live) groß genug ist. Da dieser Wert von jeder Zwischenstelle um 1 reduziert wird.
G. A. schrieb: > Man muss dann - > denke ich - nur aufpassen das der TTL-Wert im Paket (Time-to-live) groß > genug ist. Da dieser Wert von jeder Zwischenstelle um 1 reduziert wird. Layer 2 Switches tun das nicht.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.