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!
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
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!
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
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
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.
1 | 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...
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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.