Important announcement: there is an English version of this forum on
Datum:
Ich verwende in einer aktuellen Applikation einen Marvel 88E1111 - Ethernet PHY und bin mir über dessen Reset-Verhalten im Unklaren. Ich habe im Forum gesucht und einiges gefunden. Hier z.B. wird darüber berichtet, man müsse den Energiesparmodus benutzen: Beitrag "Re: Ethernet Phy zum Senden bewegen" - so jedenfall kommt es rüber. Mit dem Reset scheint es Probleme zu geben. Ich kann dort nicht mehr schreiben, daher würde ich das Thema gerne hier erörtern. Kann jemand etwas dazu sagen?
Datum:
reset low aktiv da hatte ich mal probleme das er immer im reset war ^^
Datum:
Im thread heisst es, er kommt nach dem Reset hoch, verhandelt auch, ist aber nicht sendebereit.
Datum:
Kann ich nicht bestätigen. Nach einem Reset war er immer betiebsbereit. Bisher keine Unregelmäßigkeiten festgestellt.
Datum:
Nur mal so eine Idee (ich hatte mal ein ähnliches Problem): Die meisten PHYs lesen beim Reset den Pegel an diversen Pins und konfigurieren sich damit (z. B. Autonegotiation, LED-Geblinke usw.). Näheres sagt Dir das Datenblatt Deines Vertrauens. Wenn Du den Reset über Dein FPGA auslöst und diese Pins dabei auf dem "falschen" Pegel hast, dann kannst Du den PHY leicht in einen Zustand bringen, in dem er keinen Link mehr aufbaut. Mögliche Abhilfen: - Beim Reset alle entsprechenden Pins des FPGA hochohmig schalten oder - Keine Pullups/-downs verwenden, sondern die Pegel am FPGA passend setzen oder - hinterher den PHY per MMIO umprogrammieren.
Datum:
Was aber dann das Problem mit sich bringt, dass der FPGA erstmal nichts gescheites ausgibt, wenn hard resttet wird und die Bausteine losrennen. Daher immer erst alles ruhig halten und den FGPA das board booten lassen.
Datum:
Ich benutze auch einen 88E1111 . Beim Reset ist das Timing wichtig: Erst warte ich 10 mSec. Dann wird die Reset-Leitung auch für 10 mSec aktiviert, bevor sie wieder deaktiviert wird. Und danach sollte auch noch gewartet werden, ich gebe da sogar 2 Sekunden Zeit, bevor ich etwas anderes mit dem Phy mache. Ok, die 2 Sekunden könnte man reduzieren, aber das ist in meiner Anwendung egal. Weitere Einstellungen mache ich am Phy nicht. Nach dem Reset wird ein angeschlossenes Ethernet-Kabel erkannt, und die LEDs leuchten. Das weitere Setup geht über MDIO.
Datum:
21ms muss er nach dem reset warten ist meine info
Datum:
Ich habe den PHy soweit, dass er verhandelt - der Reset kommt derzeit noch per Hand. Er braucht geschätzt 1,5 sec, baut dann den link auf und die LEDs leuchten entsprechend. Allerdings kriege ich ihn nicht dazu zu senden. Ich bin z.B. nicht sicher, was ich bei einigen Einstellungen verwenden muss. Hätte da jemand einen groben Tip, was ich alles einstellen muss? Z.B. kann man delays für TXCX and RXCLK einstellen, sowie Werte für TX_CFG und RXFILTER.
Datum:
Welches Interface wird verwendet, GMII oder RGMII? Die 1.5 Sekunden für den Linkaufbau kann auch an der Gegenseite liegen, ist also erstmal kein Grund zur Sorge.
Datum:
Mit dem Aufbau bin ich zufrieden, nun möchte ich senden. RGMII wird benutzt und das MDIO-IF.
Datum:
Bei RGMII im Gigabitmode kann man leicht beim Timing etwas falsch machen. Laut RGMII spec soll der Sender (FPGA) die Daten zusammen mit der Clockflanke ausgeben, und auf der Empfängerseite (PHY) soll die Clock 1-2.5 nsec verzögert ankommen. Die Spec empfiehlt eine lange Clockleitung. Ist natürlich besonders toll, da das mindestens 20cm wären. Für die Richtung PHY zu Switch gilt das natürlich auch. Kann man natürlich mit den entsprechenden Einstellungen für die DDR Pins am FPGA korrigieren, und auch im Marvell lässt es sich ganz sicher konfigurieren. Just in this Moment, nehme ich ein FPGA zu Marvelswitch RGMII Interface in Betrieb, ich korrigiere im Switch und verwende im FPGA die Einstellung die ohne PLL bzw DLL auskommt.
Datum:
Lattice User schrieb: > Für die Richtung PHY zu Switch gilt das natürlich auch. Bah, soll heissen PHY zu FPGA.
Datum:
Lattice User schrieb: > korrigiere im Switch Was korrigierst Du dort? Welcher switch ist das?
Datum:
R. K. schrieb: > Was korrigierst Du dort? > Dass der Switch TXC intern verzögert um TXC,TXDx abzutasten, und dass er RXC verzögert ausgibt damit der FPGA auf der Clockflanke abtasten kann. Dein Marvell PHY kann das ganz sicher auch.
Datum:
ok, danke für die Information.
Datum:
PittyJ schrieb: > Das weitere Setup geht über MDIO. Hättest Du eine grobe Einschätzung, wie lange man benötigt, um einen PYH zu bedienen zu lernen? Ich stehe vor der Aufgabe, einen Ethernet-Anschluss in unsere Designs einzubringen - 100 MBit würden für den Beginn reichen. Macht der PYH dann die gesamte Komunikation mit dem Ethernet? Es steht zudem der Entscheid an, ob man den PYH auch im FPGA absorbieren kann: Beitrag "Re: GigaBit-Ethernet Hardware?" Wäre das denkbar?
Datum:
> Macht der PYH dann die gesamte Komunikation mit dem Ethernet? nein Der PHY ist für die Verbindung und synchronisation der elektrischen Signal zuständig. Die Phy ist die unterste Schicht im Datenverkehr. Der Datenstrom wird durchgereicht. Die Daten müssen vo einer anderen Einheit bereitgestellt werden. Zusätzlich muss auf Pakete für den Datenaufbau geantwortet werden. Das ist die typische Nebenaufgabe eines Mikrocontrollers. GBit ist 100MBit ist vom VHDL-Code nicht komplizierter. Es sind aber andere Anforderungen an den FPGA. 100Mbit 25Mhz Taktfrequenz 1Gbit 125Mhz Taktfrequenz Ein Trostpflaster gibt es noch. Gbit Phys sind abwärtskompatibel und können mit 25Mhz un 100Mbit gefüttert werden.
Beitrag #2930462 wurde von einem Moderator gelöscht.
Datum:
Hättest du Da eine Beispielapplikation?
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten