opencore TRI MAC auf Spartan 6

[xilinx6 (Gast)]

Hallo zusammen,

ich versuche mich gerade an dem TRI MAC von Opencore um 10/100/1000 Mbit 
Netzwerk zum laufen zu bekommen.
Ziel ist es, dass ich UDP Pakete selbst zusammenbaue und diese mit dem 
TRI MAC verschicken kann.
Der TRI MAC von Xilinx kommt deswegen nicht in Frage, da ich nur eine 
Lizenz habe um ihn zu simulieren aber nicht um Bitstream zu erzeugen.
ethernet-lite etc. möchte ich nicht verwenden, da ich alles in ISE 
realiseren will.

Hat jemand von euch schonmal den TRI MAC von Opencore verwendet?

Ich habe ihn erfolgreich in VHDL instantiert aber wenn ich mit Chipscope 
die Hardwareleitungen zum PHY anschaue, dann sehe ich, dass ich nix sehe 
:)
Nach einem Reset ist Tx_mac_wa sehr kurz high, die anderen Signale alle 
low.
Eigentlich müsste Tx_mac_wa high bleiben, weil ich ja nichts in den FIFO 
reinschreibe ...
Hat jemand von euch einen Tipp diesbezüglich?

Weiterhin frage ich mich, kann ich manuell bestimmen, ob ich MII oder 
GMII als Verbindung benutzen möchte?
In der "Entity" steht folgendes:

output          Gtx_clk                 ,//used only in GMII mode
input           Rx_clk                  ,
input           Tx_clk                  ,//used only in MII mode

Vielen Dank.

[Duke Scarring (Gast)]

xilinx6 schrieb:
> Hat jemand von euch einen Tipp diesbezüglich?
Hast Du Dir die Reset-Polarität genau angeschaut?
Welche Hardware verwendest Du genau?

Duke

[xilinx6 (Gast)]

Reset habe ich mir angeschaut und sollte passen.
Die Hardware ist ein TE0600 von Trenz. Ich kann jedoch sicher sagen, 
dass der PHY funktioniert, da das DEMO Programm von Xilinx basierend auf 
ethernet-lite ich zum laufen bekommen habe.

Hast du mit dem Core schonmal gearbeitet?

[Duke Scarring (Gast)]

xilinx6 schrieb:
> Hast du mit dem Core schonmal gearbeitet?
Nein.
Aber der PHY (Marvel 88E1111) vom TE0600 ist der selbe, wie auf dem 
Xilinx SP601-Board.
Dort ist der Reset-low aktiv. Damit hab ich mir schon mal ins Knie 
geschossen...

Duke

[Isidor Calaghan (Gast)]

Den Reset wirst du nachgemessen haben, nehme ich an. Was macht der PHY? 
Handelt er aus?

Wenn man den MARVEL resettet, kommt der nach geschätzt 0,5s aus den 
Puschen und etabliert einen link. Dann müssten die angeschlossenen LEDs 
anzeigen, was er gefunden hat. Wenn das geht, stimmt auch der Reset. 
Wenn man dem VOR Erreichen des etablierten links mit Daten füttert, kann 
er sich schon mal vertun, habe ich festgestellt.

Desweiteren ist es so, dass man mit den Takten aufpassen muss: Gerne 
stimmen die Verschiebungen von TX_CLK zu den Daten nicht. Das muss 
angepasst werden.

[xilinx6 (Gast)]

Nun, ich sehe dass der PHY 100 Mbit ausgehandelt hat.
Was ich nicht weiß und auch noch nicht rausgefunden habe, müsste auf 
MDIO ich etwas sehen?
Der Core erzeugt MDC, aber irgendwelche Aktivitäten auf MDIO kann ich 
mit Chipscope nicht erkennen. Ist das ok?
Ich meine mich zu erinnern, dass man eigentlich den PHY nicht per MDIO 
konfigurieren muss, wenn man nichts spezielles möchte.

>Desweiteren ist es so, dass man mit den Takten aufpassen muss: Gerne
>stimmen die Verschiebungen von TX_CLK zu den Daten nicht. Das muss
>angepasst werden

Hast du da passende Constraints? Ich habe welche aber bin mir da sehr 
unsicher.
Was mich an dem Core sehr wundert, erkennt der selbstäntig ob MII oder 
GMII?

Danke.

[xilinx6 (Gast)]

Hallo zusammen,
inzwischen habe ich das Problem gelöst bekommen.
Die Siganle WRB und CSB dürfen nicht einfach auch logisch null gelegt 
werden.
Denn somit wird das erste Register des MAC überschrieben und dies ist 
leider Tx_Hwmark.
Somit wird der FIFO gesperrt!

Die Erkennung ob 1000/100/10 muss bislang der User machen. Man könnte 
auch über MDIO es erkennen bzw. die Signale des PHY auswerten wie die 
LEDs in diesem Falle.
Also wenn 100Mbit gewünscht ist, muss der Default Value des Register 
Speed angepasst werden.