www.mikrocontroller.net

Forum: FPGA, VHDL & Co. 100MBit Ethernet mit Spartan 3E Starter Kit


Autor: Jonas W. (jonw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Soo… Ich bin jetzt schon ne ganze Weile im Netz unterwegs gewesen, habe 
viele Stunden mit VHDL-gehacke verbracht und bin trotzdem nicht 
sonderlich weiter gekommen.
Ich habe auf Basis von einem Beispiel, das ich im Netz gefunden habe, 
UDP/IP/Ethernet-Empfang auf dem genannten Board implementiert, soweit 
ich das überprüfen konnte funktioniert das auch.
Jetzt habe ich angefangen, das Senden zu implementieren und da geht 
irgendwie garnichts. Zu erwähnen ist, dass ich versuche 100MBit zu 
senden, d.h. die tx_clk taktet mit 25MHz, während die Board-Clock auf 
50MHz läuft. Das kommt mir etwas knapp vor, aber in der Theorie sollte 
das gehen.

Ich habe das ganze auch mal simuliert und das Ergebnis scheint 
anständig. Wenn ich das ganze aber auf den FPGA haue, kann ich in 
Wirschark keine Pakete sehen, statt dessen gehen mehr oder weniger 
abwechselnd die “errors” und “frame”-Fehlerzähler in Linux' ifconfig 
hoch. Da geht also irgendwas schief, entweder bei der CRC oder sonstwo. 
Ich hab mir eben diese mal auf dem LCD ausgeben lassen und festgestellt, 
dass die trotz konstanter Daten eben nicht konstant ist (aber dennoch 
größtenteils konstant, meistens kommt der Wert aus der Simulation raus). 
Da dies in der Simulation nicht auftrat, habe ich den Verdacht, dass da 
irgendwas Timing-artiges nicht läuft.
Sowas ähnliches hatte ich beim Implementieren der Empfangsmodule. Dort 
konnte ich das lösen, indem ich Zwischensignale einrichte, was ich jetzt 
auch für TX gemacht (der ganze next*-Kram) habe – ohne, dass es etwas 
gebracht hätte.

Den CRC-Generator habe ich von http://outputlogic.com/?page_id=321.

Also zusammengefasst:
- 100MBit-Ethernet-TX auf Spartan 3E Starter Kit Board
- Simulation ok, Realität nicht
- CRC nicht konstant bei konstanten Daten
- TX-LEDs blinken
- MAC sollte stimmen, das Paket sollte auch bei falscher CRC aber nicht 
mit einem “frame”-Error gedroppt werden.

Angelegte (Test-)Signale:
  clk                 kommt vom Board und hat 50MHz
  ethSrcMAC         = x"00AAAAAAAAAA"
  ethStartTX          hängt von einem Taster ab
  ethDstMAC         = x"001BFC25B7AD"
  ethProtocol       = x"0800"
  ethPayloadLength  = x"FF"
  ethTXData         = x"FF"
  tx_clkd             kommt vom PHY und hat 25MHz (laut Datenblatt)

grüße!

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonas W. schrieb:
> - Simulation ok, Realität nicht
> - CRC nicht konstant bei konstanten Daten
Das sind relativ eindeutige Symptome.


> clk                 kommt vom Board und hat 50MHz
>   tx_clkd             kommt vom PHY und hat 25MHz
Die Takte sind nicht korreliert. Wie sieht der Übergang aus?
Da gehört ein asychrones FIFO hin.
Stichwort: Clock-Domain-Crossing

Duke

Autor: Jonas W. (jonw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Aufklärung. Ich hatte eigentlich gedacht, dass die ganzen 
Puffer das ausreichend synchronisieren.
Kannst du mir vielleicht auch noch sagen, warum das beim Empfangen 
sauber funktioniert?

grüße!

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonas W. schrieb:
> ganzen Puffer das ausreichend synchronisieren.
Welche Puffer?
In EthernetTX.vhd sehe ich keine Puffer.

> Kannst du mir vielleicht auch noch sagen, warum das beim Empfangen
> sauber funktioniert?
Zufall? Werden da auch die CRCs gecheckt?

Duke

Autor: Jonas W. (jonw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Okay, ich habe die Zeit gefunden, das mit einem asynchronen Fifo 
dazwischen umzubauen. Nun gibt er mir bei Place&Route aber folgenden 
Fehler:
---
Place:1018 - A clock IOB / clock component pair have been found that are 
not placed at an optimal clock IOB / clock site pair. The clock 
component <tx_clk_BUFGP/BUFG> is placed at site <BUFGMUX_X1Y0>. The IO 
component <tx_clk> is placed at site <IPAD159>.  This will not allow the 
use of the fast path between the IO and the Clock buffer. If this sub 
optimal condition is acceptable for this design, you may use the 
CLOCK_DEDICATED_ROUTE constraint in the .ucf file to demote this message 
to a WARNING and allow your design to continue. However, the use of this 
override is highly discouraged as it may lead to very poor timing 
results. It is recommended that this error condition be corrected in the 
design. A list of all the COMP.PINs used in this clock placement rule is 
listed below. These examples can be used directly in the .ucf file to 
override this clock rule.
< NET "tx_clk" CLOCK_DEDICATED_ROUTE = FALSE; >
---

Wenn ich das richtig verstehe, ist das eine Sache, die ich 
Hardwareseitig nicht beheben kann. Bevor ich das jetzt aber mittels ucf 
umgehe, würde ich gerne wissen, was die Implikationen sind?
Anscheinend kann ich tx_clk nicht als echte clock nutzen. Wie muss ich 
das denn dann implementieren?
Ich bin mir nicht sicher, welche Zusatzinformationen da für euch 
hilfreich sind. Wenn irgendwas fehlt, bitte nachfragen!

grüße

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jonas W. schrieb:
> Anscheinend kann ich tx_clk nicht als echte clock nutzen. Wie muss ich
> das denn dann implementieren?
Doch, Du kannst tx_clk als echten Takt verwenden. Allerdings hat der 
Boarddesigner ein Eingangspin verwendet, welches nicht mit dem 
Taktnetzwerk verbunden ist.
NET "tx_clk" CLOCK_DEDICATED_ROUTE = FALSE;
Indem Du die obige Zeile im .ucf hinzufügst, sagst Du dem Tool, hier 
ausnahmsweise einen Takt über das gewöhnliche Routingnetz zu schicken.

Das ist da vermutlich bzg. Jitter, Temperatur- und Spannungsstabilität, 
Laufzeiten etc. nicht so günstig, aber in diesem Fall nicht ohne 
Hardwareänderung machbar.

Duke

P.S.: Ich mußte diesen Zusatz auch ins .ucf packen...

Autor: Jonas W. (jonw)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hmm… Ich hab das nun mal entsprechend umgesetzt und auch noch einen 
Fehler beim setzen von tx_en (zumindest war das Simulationsergebnis 
falsch) beseitigt aber ansonsten nicht viel geändert (glaube ich, es 
lagen Prüfungen dazwischen) [Habe den Fifo auch noch verkleinert und mit 
einem Clock-Division-Artiken Konstrukt den Takt auf der Schreiben-seite 
des Fifos verringert, damit ich mit dem kleineren Fifo auskomme].

Jedenfalls tuts immer noch nicht. Das ist, was ifconfig eth0 zu dem 
sagt, was der FPGA da sendet:
          RX packets:0 errors:165746 dropped:0 overruns:0 frame:165746

Wenn ich mit weiteren Informationen helfen kann, lasst es mich bitte 
wissen!

grüße

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.