Guten Abend. Ich möchte eine bidirektionale Verbindung zwischen einem FPGA (Virtex-6,ML605) und einem PC mittels Ethernet realisieren, um Datensätze (Temperatur, Drehrate etc.) zwischen dem FPGA und dem PC auszutauschen. Ich habe bereits eine solche Datenverbindung über die USB-Schnittstelle in VHDL realisiert. Der Umstieg auf eine Ethernet-Verbidung soll einen Geschwindigkeitsvorteil liefern. Der Aufwand für den Umstieg auf eine Ethernet-Verbindung seitens des FPGAs sollte sich in Maßen halten. Ich habe hier im Forum mehrere Artikel zu dem Thema gelesen. (z.B. http://blogs.msdn.com/b/satnam_singh/archive/2011/02/11/using-the-virtex-6-embedded-tri-mode-ethernet-mac-wrapper-v1-4-with-the-ml605-board.aspx). Dieser IPCore könnte interessant sein. Allerdings sind in dem Artikel nur die wenigsten Anschlüsse am Core belegt (bzw. beschrieben was mit diesen geschieht). Im Datenblatt zum Core sieht es aus, als müsste hier noch einiges an Arbeit investiert werden (was nicht schlimm wäre). Vielleicht hat ja hier jemand mit genau diesem Problem (Daten von FPGA an PC über Ethernet) schon Erfahrung gesammelt und kann mir etwas zum erwarteten Aufwand sagen. Bzw. etwas dazu sagen, ob ich mit dem gewählten Core auf dem Richtigen Weg bin und was ich zu beachten habe. Vielen Dank.
Es gibt zwei Möglichkeiten: 1. Du hast einen Soft-Core-Prozessor zur Verfügung: -> Die Ethernet-Implementierung ist nicht schwer. Halte dich an die Example-Designs von Xilinx und dann kommt das irgendwann hin. 2. Ohne Prozessor: -> Du musst alles in VHDL programmieren (ARP, IP, UDP). Das ist ne Menge Arbeit. Gruß Marius
Danke dir. Mit 1. meinst du dem von mir angesprochenen Core? Richtig?
Nee der o.g. Core ist nur der MAC, da fehlen noch ein paar Layer darüber. Für TCP/IP macht man das am besten mit einem Softcore Prozessor, z.B. dem MicroBlaze. Sonst wird das einfach viel zu viel Aufwand.
Danke dir. Habe wie gesagt keine Erfahrungen mit Ethernet. kannst du mir noch sagen mit welchen example desings es sinnvoll ist zu beginnen. Eventuell einen link. Einen schönen Tag dir und nochmals danke
Puh, das weiß ich auch nicht. Wenn, dann ist es bei Xilinx sicherlich sinnvoll, sich in EDK einzuarbeiten, falls du da eine Lizenz hast. Denn da gibts diese ganze Prozessor-Sache. Wir hatten das damals auf dem Virtex 4 FX mal mit dem PPC Prozessor angefangen, war aber zu aufwendig. Für UDP Streaming brauchst du das sicherlich nicht, da müsstest du mal schauen, Xilinx hat da ein paar Beispiele, zum Beispiel beim SP605 Board ist da was dabei, um Videodaten über GbE zu übertragen. Vielleicht hilft das.
wenn du nur UDP brauchst dann kannst du das ganze in Hardware machen. Dann brauchst du knapp 2 Wochen um dich in die ganzen Layer vom OSI-Modell einzuarbeiten und das GMII/RGMII/SGMII-Interface zu deinem Phy hinzubekommen. Dann noch mal 2-4 Wochen bist du deine ersten Pakete sicher versenden und empfangen kannst. Dann brauchst du ca 2 Wochen um einen sehr primitiven Controller zu bauen um die ganze Ethernet-Verbindung zu steueren : ARP-ARP-Antwort, Port beantworten Port ablehnen, etc blablabla. Tja und dann die Anbindung an deine Anwendung, also wie du die Pakete füllst mit was etc und was mit den ankommenden Paketen passieren soll.. das kannst nur du bestimmen.. Wenn du keine Ahnung hast von den Softcores, dann ist UDP in Hardware schon ne ordentliche Alternative und tja je nachdem wie gut du dich halt mit den ganzen Protokollen und Layer auskennst entsprechend dauert es dann länger oder kürzer. TCP in Hardware würde ich aus eigener Erfahrung dringenst von Abraten, ich musste das machen und das war im Nachhinein sehr lehrreich... und zwar wie man es nicht machen sollte!! Wenn du ein bissel Ahnung von den Softcores hast oder gar nen SoC hast und die Lizenzen dazu dann ließ dir nen Paper über die gängigen 4-5 TCP/IP-Stacks durch (davon sind fast alle irgendwo für free zu bekommen) und dann nimm den der dir am besten zusagt (Leistung <-> Resourcen). Die Software-Schnittstellen zum uip-Stack zum Beispiel sind relative gut verständlich und simpel ausgelegt.
:
Bearbeitet durch User
Hat der Virtex 6 keinen hard core zur Verfügung? Da gibt es doch eine PPC Architektur, die ist aber auf dem Demo PCB nicht verbaut, nehme ich an(?)
Hard Core ja, aber das ist nur der MAC. PPC gabs nur bis zum Virtex 5. Dann gibts sowas erst wieder beim Zynq.
Wie siehts alternativ mit einem externen Hardware TCP/IP Chip à la Wiznet aus?
Ich hab das mal mit einem Hardware TCP/IP Stack Wiznet W5300 gemacht. Direkt memory gemappt ans FPGA, das dicke Datenblatt durchgelesen und in VHDL mit einer recht laenglichen Statemachine bedient. Hat funktioniert, ist aber glaube ich nicht besonders elegant und flexibel.
NoName schrieb: > Der Umstieg auf eine > Ethernet-Verbidung soll einen Geschwindigkeitsvorteil liefern. Ethernet oder TCP/IP over Ethernet? MfG Klaus
noname schrieb: > Danke dir. Habe wie gesagt keine Erfahrungen mit Ethernet. kannst du mir > noch sagen mit welchen example desings es sinnvoll ist zu beginnen. > Eventuell einen link. Einen schönen Tag dir und nochmals danke Hier sind die etlichen Ethernet Ref-Designs für diverse Digilent Boards SP601 sample VHDL project with the ethernet link http://forums.xilinx.com/t5/Xilinx-Boards-and-Kits... XAPP1026 http://www.xilinx.com/support/documentation/applic... Frage: Hast du schon Erfahrung mit dem MicroBlase Soft-Core? Gruss Holger.
Embedded Development Kit (EDK). Mit dem EDK erstellst du ein Netz-listen Modell. Xilinx EDK Tutorial - A Guided Tour of the Platform Studio - Part 1 bis 3 Ansehen Je nach Board z.B SPARTAN 3E wird ein Modell erstellt, und ein xxx.elf-File I/O LED,RS232, ETHERNET … ########################################################### Xilinx EDK Tutorial - Sharing BRAM between Hardware and Software System.mhs File https://www.youtube.com/watch?v=uMEqWmaX6aE Hint: Xilinx EDK Tutorial - A Guided Tour of the Platform Studio - Part 3 Topic: Inject the xxx.elf File ########################################################## Xilinx EDK Tutorial - Adding custom IP to an EDK Project - Part 3 https://www.youtube.com/watch?v=DkjVXeqRKjE Topic: Schreiben via PLB-BUS auf ein 32 Bit-Port in C. Viel Erfolg. Gruss Holger.
Hi NoName, (Virtex-6,ML605) Derivat. UDP-Header mit 64 bit und Infos für das Project. Link: http://www2.informatik.hu-berlin.de/~brueckne/diplomarbeit.pdf Zum Erstellen des Hardwareprojekts wird zunächst der Base System Builder, einem Assistenten zur Erstellung eines Grundsystems im Xilinx EDK, genutzt. Damit dieser auch mit dem verwendeten Board funktioniert, stellt der Board-Herstelller passende XBD-Dateien bereit. Das sind Boardbeschreibungsdateien, in denen die vorhandene Hardware beschrieben wird. Somit kann der Assistent die passenden Module zur Auswahl stellen. Für das dann erstellte System werden auch passende UCF-Dateien angelegt. Diese enthalten Constraints für den Place-and-Route-Algorithmus. Unter anderem ist dort festgelegt, mit welchen Pins am FPGA der Algorithmus interne Leitungen verbinden soll. Zudem werden Bedingungen über Leitungseigenschaften formuliert, die zeitkritisch sind. Für besondere Situationen ist es möglich genau zu beschreiben, wo im FPGA bestimmte Hardwaremodule platziert werden sollen. Das mit dem Assistenten erstellte Projekt ist (unter anderem durch die passende UCF-Datei) in der Regel sofort auf dem Board lauffaehig. Fazit: Du hast ohne das spezielle passende Board-Support Package erst mal nur ein Skeleton. Trap:#1 Die BSP Tools haben dann z.B den Phy nur auf 10MHz, und nicht 100MHz Also muss man an den Phy Pinning via system.mhs file . system.UCF file manuell was machen. ########################################################## Here is the solution: Tie nINT/TXER/TXD4 to GROUND! This pin is connected to FPGA-PIN "P2". 1. In your system.UCF file, add the following line: NET Ethernet_TX_ERR LOC = "P2" | IOSTANDARD = "LVCMOS33"; 2. In the system.mhs file, add the following line in the first "port" section: PORT Ethernet_TX_ERR = net_gnd, DIR = O The save and select "rescan repositories". ######################################################################## #### Vielleicht hilft das. Gruss Holger. Xilinx Embedded System - Ethernet Communication (Spartan 3E) Spartan XC3S50AN Ethernet Communication
Holger Harten schrieb: > Hast du schon Erfahrung mit dem MicroBlase Soft-Core? Na ein Soft Core ist ja sicher nicht die erste Wahl, wenn es um Hochgeschwindkeit geht.
Hallo Ingenieurbüro Wagner ! > Na ein Soft Core ist ja sicher nicht die erste Wahl, wenn es um > Hochgeschwindkeit geht. Ich möchte erst mal auf Geschwindigkeit verzichten. Es geht mit um einen Ansatz für einen eigenen Ethernet MAC core, der via VHDL und Microblaze C-Code besteht. Ansatz#1: "Digilent Design Contest 2011" BitHound - An FPGA Based Logic Analyzer Open Source One for the "ATLYS Spartan-6" FPGA-Board from Digilent http://www.bastli.ethz.ch/index.php?page=BitHoundEn As Ethernet is used to connect the Logic Analyzer with the PC that runs the client software 100MBit/s Ethernet interface for fast data transfer BitHounds FPGA design contains an 8Bit AVR CPU softcore and several other opensource cores from OpenCores. Ansatz#2: ######### To do: -Xilinx_Spartan3E_RevD_v2_2_0.xbd XEmacLite_FlushReceive(&lp->EmacLite); Flush Receiver ??? to kill old received artefacts. --------------------------------------------- Also per MicoBlaze C-Code wird der Ram-Buffer gefüllt also Byte-Stream. Danach wird der VHDL-Phy Code aktiv. Die VHDL Phy sendet den Byte-Stream serriel als Bit-Stream raus. Als Ethernet MAC core. Phy-Funktionen: int XEmacLite_PhyRead(XEmacLite *InstancePtr, u32 PhyAddress, u32 RegNum, u16 *PhyDataPtr); int XEmacLite_PhyWrite(XEmacLite *InstancePtr, u32 PhyAddress, u32 RegNum, u16 PhyData); int XEmacLite_Send(XEmacLite *InstancePtr, u8 *FramePtr, unsigned ByteCount); u16 XEmacLite_Recv(XEmacLite *InstancePtr, u8 *FramePtr); void XEmacLite_EnableLoopBack(XEmacLite *InstancePtr); void XEmacLite_DisableLoopBack(XEmacLite *InstancePtr); Link: http://www.cs.indiana.edu/hmg/le/project-home/xilinx/ise_13.2/ISE_DS/EDK/sw/XilinxProcessorIPLib/drivers/emaclite_v3_00_a/src/xemaclite.h http://www.cs.indiana.edu/hmg/le/project-home/xilinx/ise_13.2/ISE_DS/EDK/sw/XilinxProcessorIPLib/drivers/emaclite_v3_00_a/ ######## ############ Viel Erfolg. Gruss Holger ############ PHY und MAC Chips: LAN83C185 PHY Register 83c185.pdf AMD AM79C874 PHY Datasheet Ethernet MAC core National Semiconductor Ethernet products DP83847 Davidcom mit S-Ram Interface.
:
Bearbeitet durch User
Darf ich fragen was der MAC Core können soll? Ich wäre an einem GBit-Core interessiert.
Markus Wagner schrieb: > Darf ich fragen was der MAC Core können soll? Ich wäre an einem > GBit-Core interessiert. Gundlagen auf der Bit-ebene mit dem PHY 4 Bit Port. Damit kann man mit dem Phy Hand-Shake fahen. Wenn man die Spec. und Register kennt. Siehe ZILOG SCCc. Controller 4 Byte elastic Buffer. Frage: was hast du für einen PHY. Alkaska Marvel 1111 ? ################################################################# LAN83C185 PHY Register 83c185.pdf SMSC LAN83C185 PHY Register Interface and Register Descriptions Title MII Synchronisierung, Ethernet ++++++++++++++++++++++++++++++++++++ Link: @Markus Wagner Beitrag "MII Synchronisierung, Ethernet" Phy DatenBlatt ist auch dabei. 4_bit_Bus-Turn-Around time ist 1 Cycle. wait--'state #################################################### via Modi switch from Pre-able-tooSync.. to in Read-Mode. (Transit vector [0][1].[0] via R_ERR[0]} PIN) in LAN83C185 PHY Register. Gruss Holger. Tip: Prozess >Leitfaden http://www.ethercat.org/pdf/german/EtherCAT_Introduction_DE.pdf ##############################################################
Angehängte Dateien:
LINK für die Präambel ... und Iterface von Rene Fa. Dossmatic. Link: Beitrag "Ethernet GMII" Hier ist noch ein Bild für Read/Write. Dér write ist nach dem WR_EN und clk-edge noch mit 2 delay behaftet ??. Anhang: Phy_Bus_Fpga_50_get_phy25_MHz.PNG Gruss Holger. Mit dem Loopback habe ich 2 Zyklen bis die Daten von der TX-Pipe in die RX-Pipe gehen. (Serielles-Shift-Reg) --> PHY. [][]--[][] Der Loopback ist ohne Externen HUB oder PC oder Router so testbar. bingo>. Beim Loopback Mode ist der TX-EN nicht benutzt. ?? Nur der TX-Takt via TX[ERR_Staus-Monitor]...
:
Bearbeitet durch User
Source-Coode: STM32F4DISCOVERY_Ethernet-Phy.zip Anhang ist eine MCU mit 150 MHz. als Webserver. Der Phy hat aber nur 2Bit Data-Pinne, und ist von Texas Inst. ------------------------------------------------------------- Zusatz: Media Management Port (MMI) Das MMI Port am PHY ist ein 1-´Wire Bi-dirctonales Port. Der Clock am MMI ist auf max. 2,5 MHz bgrenzt. ... Eine Präambel muss mit 32 High-Bits & CLK-MMI das MMMI Port enablen.. ########################################################### Vor dem Schreiben auf das Loop-Back-Data-Word muss noch ein overwite Register beschrieben werden. So eine art W_en/Flip-Flop. Danach kann man erst zB. den Loop-Back Mode aktivieren. Gruss Holger.
Holger Harten schrieb: > Der Loopback ist ohne Externen HUB oder PC oder Router so testbar. Weiter geht es wenn man einfach nur 2 eigene Stationen vernetzen will. .... also ohne das ganze Overhead, sondern nur erst mal als Serial-stream-link. Siehe hier das Anhang: wp-01212-high-speed-link-modeling-simulation.pdf ------------------------------------------------------------------------ Der PHY Alaska 1111 ist z.B so einstellbar das er ein Auto-Paket handling kann. (Advanced Caperbilities).. Beispiel sind Jumbo Pakete, die daran scheitern da die jeweiligen Router untereinander das nicht immer richtig handeln wollen, bzw der admin/user das richtige Setup können. Auto-Negation, Packet#, Time-Stamp..Auto-Answer. Also verstehen sich im Router der via user Config-Setup eingestellt ist, nicht jeder PHY von Marvel mit einem von Acronix, Tabula. Und wenn man den Router abschaltet ist das Config-Setup weg. Und dann fängt man an zu suchen...??? ######################################################################## Somit kann man aber sein eigenes Protokoll&Front-End bauen, um erst mal Daten via PHY[]<--<><<>--|>>to PHY[] mit dem ETERNET Kabel zu übertragen.
Ich will Messdaten per Ethernet übertragen. Hat jemand einen guten Vorschlag für die das Datenprotokoll?
"LXI is the power of Ethernet and the Web applied to Test & Measurement (T&M) instruments, offering you new possibilities in test systems – local, remote, distributed and time-aware." http://www.lxistandard.org/
René D. schrieb: > Ich will Messdaten per Ethernet übertragen. Was für Daten? - Eine Art Echtzeitdaten?, Also verlieren die nach einer gewissen Zeit ihre Bedeutung? Bsp. Positionsangaben. - Oder ist jedes Messbit unentbehrlich, egal wann es ankommt? Sollen die Daten nur über eine Direktverbindung zwischen 1 Gerät und 1 Rechner ausgetauscht werden ? Soll das ganze auch über ein lokales Netzwerk funktionieren? Oder vllt sogar über das gesamte Internet?? Das ganze lieber mit oder ohne SoftCore?
Trundle Trollkönig schrieb: > René D. schrieb: >> Ich will Messdaten per Ethernet übertragen. > > Was für Daten? > > - Eine Art Echtzeitdaten?, Also verlieren die nach einer gewissen Zeit > ihre Bedeutung? Bsp. Positionsangaben. > - Oder ist jedes Messbit unentbehrlich, egal wann es ankommt? > > Sollen die Daten nur über eine Direktverbindung zwischen 1 Gerät und 1 > Rechner ausgetauscht werden ? > > Soll das ganze auch über ein lokales Netzwerk funktionieren? > Oder vllt sogar über das gesamte Internet?? > > Das ganze lieber mit oder ohne SoftCore? Ich bin noch in der Findungsphase. Ich will einen ADC an meinem FPGA anknoten. Diese Daten will ich auf dem PC darstellen. Muss nicht echtzeitfähig sein. Hauptgrund Daten erstmal durchreichen und sehen. Es soll schon ein standardisiertes IP4 Protokoll sein. Dann ist es im Lokalen Netzwerk sichtbar. Ich dachte an eine einfache UTP-Verbindung. TFTP oder ähliches. Erstmal ohne Softcore als Schnellschuss. Und dann Ausbaustufe II werde ich nicht um einen Softcore herumkommen, wenn dann Interaktionen laufen sollen.
René D. schrieb: > Es soll schon ein standardisiertes IP4 Protokoll sein. Dann ist es im > Lokalen Netzwerk sichtbar. Warum IP? Was bringt dir das? Tausche Daten einfach erstmal mit rohen Ethernet-Frames aus. Das ist sehr viel einfacher. Einen kompletten IP-Stack in Hardware zu implementieren ist Wahnsinn. Aber Achtung: Ethernet ist unzuverlässig; Paketverlust ist keine Ausnahme, sondern der Normalfall. Da würde dir IPv4 und TFTP aber gar nicht helfen. (Und wenn du doch schon IP implementierst, dann lieber IPv6)
greg schrieb: > Tausche Daten einfach erstmal mit rohen > Ethernet-Frames aus. Erkläre mal wie man von einem FPGA über Ethernet bis zum Betriebssytem vom PC Daten transferieren kann ohne mindestens die Layerebene von UDP und TCP zu verwenden?? Und erkläre mal warum Ethernet-Verbindungen = Datenverlust sein soll, erst recht bei lokalen Netzwerken?? Und wieso IPv6 für sein internes Netzwerk?? Und erkläre mal was an einem UDP-Stack für Peer-Peer-Verbindungen so kompliziert sein soll, d.h. Rene D. das nicht in 2-3 Monaten hinbekommen soll?? konkret Rene für Hardware-Ethernet brauchst du: - Gmii-Interface - Analysemodul für die ankommenden Pakete : Layer 2 und Layer 3 (OSI) - und wenn du UDP als Protokoll verwenden willst, brauchst nen Modul was folgende Protokolle beherrscht, dir also entsprechende Antwortpakete schnüren kann: - ARP-Pakete - ICMP-Pakete - UDP-Pakete Für lokale Netze oder Peer2Peer reicht UDP vollkommen aus, da wird, wenn du nicht vollkommen verrückte Sachen machen willst, kein Datenverlust auftreten. Wenns nur 100Mbit sein sollen, würde ich aber einen einfach uC empfehlen mit open-source TCP/IP oder UDP-Stack. Die brauch man nur noch anpassen. Für mehr wie GBIT, kommt dann eher nen FPGA oder SoC in Frage weil da gibts nicht viele uC die das können. Einer wäre z. B. der von Lothar erwähnte i.MX6. Der ist bzw war aber relativ teuer!
Die Antwort von Greg war hohl. Ich habe kein einzigen PC mit IP6 laufen, um mir die Pakete anzuschauen. Reicht aus. > konkret Rene für Hardware-Ethernet brauchst du: > > - Gmii-Interface Habe ich. Ich kann Pakete versenden und auch empfangen. Kann im Wireshark meine ankommenden Pakete sehen. Die eingehenden Pakete habe ich mir über die COM TX 112500baud ausgegeben. > - Analysemodul für die ankommenden Pakete : Layer 2 und Layer 3 (OSI) Ja hier klemmts es bei meinem Wissen. Meinst du die Checksumme kontrollieren oder muss ich hie noch mehr machen? > - und wenn du UDP als Protokoll verwenden willst, brauchst nen Modul was > folgende Protokolle beherrscht, dir also entsprechende Antwortpakete > schnüren kann: > - ARP-Pakete ARP sehe ich als lösbar an. > - ICMP-Pakete Das dürfte ping sein. Für Servicefälle. > - UDP-Pakete Pakete von der Anwendung. Ich will es in meinem FPGA hineinbekommen. War schon mal die richtige Richtung.
Trundle Trollkönig schrieb: > Erkläre mal wie man von einem FPGA über Ethernet bis zum Betriebssytem > vom PC Daten transferieren kann ohne mindestens die Layerebene von UDP > und TCP zu verwenden?? > Raw Sockets unter Unixoiden, unter Windows mit NDIS. > Und erkläre mal warum Ethernet-Verbindungen = Datenverlust sein soll, > erst recht bei lokalen Netzwerken?? > Ethernet (1000BASE-T) hat eine spezifizierte bit error rate, die nicht unbedingt das gelbe vom Ei ist. 10^-10, d.h. es kann alle 10 Sekunden ein Fehler auftreten und man bewegt sich noch in der Spezifikation. Dazu kommen softwareseitige Timing- und Durchsatzprobleme auf PCs. Der Fall, dass Pakete verloren gehen, existiert nicht nur in der Theorie, selbst bei Direktverbindungen. Es ist deshalb explizit vorgesehen, dass Protokolle auf höherer Ebene fehlertolerant sind. Aber IP macht keine Retransmission. Eigentlich müsste man wohl TCP oder SCTP implementieren, und das ist dann alles andere als trivial. > Und wieso IPv6 für sein internes Netzwerk?? > Zukunftssicherheit, einfacher. > Und erkläre mal was an einem UDP-Stack für Peer-Peer-Verbindungen so > kompliziert sein soll, d.h. Rene D. das nicht in 2-3 Monaten hinbekommen > soll?? > 2-3 Monate ist für mich etwas anderes als ein "Schnellschuss" zum Testen. Da gilt KISS.
greg schrieb: > Raw Sockets unter Unixoiden, unter Windows mit NDIS. Nachtrag: mit PCap gibt's alternativ sogar eine portable Lösung, hat aber u.U. nicht die gleiche Performance.
Also ich hab hier ein in Hardware gegossenen Ethernet TCP/IP-Stack entwickelt und versende seit etwa 3 Monaten jeden Tag ca. 2 Mio - Pakete mit bis zu 20 MB/s. Ich habe noch nicht ein einziges Mal, außer wenn ich mein Verilog-Code modifiziert habe und darum meine Pakete falsch zusammengebastelt habe, gesehen das meine Resend-Funktion angesprungen ist! Nicht ein einziges mal ein verschwundenes oder falsches Paket!! Da meine Gegenstelle aufm Pc ebenfalls die Konsistenz der Daten checkt, gehe ich davon aus solange du nicht irgendeinen starken Sender in der Nähe deines Cat 5 Kabels aufstellst der wirklich Bitfehler erzeugt oder Windows so stark auslastest das die Tcp-Subroutinen deine Daten nicht mehr weiterschaufeln können, gibt es bei Peer2Peer auf 5 Metern keine Bitfehler. Kurz zu deinem Vorgehen Rene: - Das Einarbeiten in das OSI-Schichtenmodell kann ich dir leider nicht abnehmen, aber... - Der Flow ARP-Pakete -> ARP-Antwort -> UDP-Paket mit Datenanfrage -> UDP-Pakete mit Datenantwort -> ....Repeat bis alle Daten rüber -> Fertig Nebenzweig : -falls falscher Port angefragt wird ICMP - Paket mit Port-Unreachable ... sollte relativ einfach zu verstehen sein und es gibt haufenweise Literatur zum Nachlesen Noch was: 1.Beim aktiven Datentransfer über Udp verändern sich außer dem Daten-Payload nur 2 Bereiche im Header vom UDP-Paket: IPID-Nummer (2 Byte) und dadurch auch die Header-Checksumme (ebenfalls 2 Byte). IPID- Nummer für jedes Paket + 1 und Checksumme für jedes Pakete - 1, da die Checksumme nach der Berechnung noch invertiert wird. D.h. wenn du dir ne FSM geschrieben hast die erstmal den ganzen quatsch mit ARP abarbeitet, kannst du dir ne relativ einfache FSM schreiben die dir die UDP-Pakete zusammenbaut. 2. CRC32 immer parallel zur Übertragung berechnen und einfach am Ende ranhängen, weil der ist von jedem Byte im Pakete abhängig (außer der Präamble!!) Das ganze ohne Gewähr, da ich kein UDP sondern TCP/IP verwende, das wird ohne ICMP-Protokoll geabreitet. Sachen wie Port öffnen/schliessen/abweisen wird über Tcp geregelt.
René D. schrieb: > Ja hier klemmts es bei meinem Wissen. > Meinst du die Checksumme kontrollieren oder muss ich hie noch mehr > machen? Ja Ebene 2 und 3 sind zur Identifizierung von den Gesrpächspartnern da, d.h. du musst die 4 Bytes Sende- und 4 Empfängeradresse (IP) checken ob die korrekt sind, ebenfalls muss du die beiden jeweils 6 Byte Mac-Adressen checken. Es empfiehlt sich einen Mac-Filter schon im GMII-Interface einzubauen, der die ersten 6 Bytes der eingehenden Pakete checkt und alles aussortiert was nicht Boradcast oder für deine individuell festgelegt MAC ist. Den Port musst du ebenfalls checken, dann weißt du das auch die richtige Applikation vom Pc dich angesprochen hat und nicht durch Zufall irgendein anderes Programm an deine IP und MAC Pakete versendet (ist zwar relativ unwahrscheinlich aber sicher ist sicher). Ich unterscheide zum Beispiel am Port an welche Module im FPGA ich den Datenpayload weiter versende, bsp Port 80 -> ok Webserver -> an HTML-Server auf uC weitersenden...etc. Dann solltest du sicherheitshalber auch die Paketlänge checken, weil du damit das erste Datenbyte im Stream lokalisieren kannst (wo dann deine individuelle Kommandos drin sind .. Daten so und so sende etc). Meistens ist der Header immer gleich lang, aber es gibt Optionbytes die unterschiedlich lang sein können, daher sicher ist sicher. Das wären so die Kernpunkte die mir gerade einfallen, welche ich zur Analyse eingehender Pakete verwende. Optional wäre ein Sicherheitscheck der UDP-Header-Checksumme, aber die ist unabhängig vom Daten-Payload, daher hab ich das weggelassen und lasse nur die CRC32-Checksumme (abhängig von jedem Byte des Pakets) vom PHY direkt checken.
Trundle Trollkönig schrieb: > René D. schrieb: >> Ja hier klemmts es bei meinem Wissen. >> Meinst du die Checksumme kontrollieren oder muss ich hier noch mehr >> machen? > > Ja Ebene 2 und 3 sind zur Identifizierung von den Gesrpächspartnern da, > d.h. du musst die 4 Bytes Sende- und 4 Empfängeradresse (IP) checken ob > die korrekt sind, ebenfalls muss du die beiden jeweils 6 Byte > Mac-Adressen checken. Es empfiehlt sich einen Mac-Filter schon im > GMII-Interface einzubauen, der die ersten 6 Bytes der eingehenden Pakete > checkt und alles aussortiert was nicht Boradcast oder für deine > individuell festgelegt MAC ist. Den Port musst du ebenfalls checken, > > Optional wäre ein Sicherheitscheck der UDP-Header-Checksumme, aber die > ist unabhängig vom Daten-Payload, daher hab ich das weggelassen und > lasse nur die CRC32-Checksumme (abhängig von jedem Byte des Pakets) vom > PHY direkt checken. Genau so will ich es machen. Die CRC32 checkt bereits die Phy? Kann die Marvell88E1111 das auch? Also ich hab hier ein in Hardware gegossenen Ethernet TCP/IP-Stack nicht schlecht, TCP/IP wollte ich dann doch im Softcoreerschlagen. Ich will zumindest ein paar Grundfunktionalitäten in VHDL haben. Sonnst ist der Softcore nur im Interrupt.
René D. schrieb: > Also ich hab hier ein in Hardware gegossenen Ethernet TCP/IP-Stack > nicht schlecht, Die Design-Entscheidung ist nicht auf meinem Mist gewachsenen und hätte ich meine jetztige Erfahrung damit würde ich mich auch wesentlich vehmenter gegen diese Entscheidung aussprechen. Es gibt heute SoC, wie den Zynq oder auch ein normaler Softcore, die schaffen die gefordernten Datenmenge von 125 MB/s locker (vom Zynq weiß ich es), da lädst du dir bspw. den Lw-Stack runter (free, opensource) lädst den da rein, konfigurierst ein bissel und wenn du nicht ganz auf den Kopf gefallen bist in C (im Gegensatz zu mir) dann läuft das Teil in nem Monat mit mehr als 90 % max Speed.
René D. schrieb: > Ich will Messdaten per Ethernet übertragen. Hat jemand einen guten > Vorschlag für die das Datenprotokoll? Hier ist das ganz gut aufgeführt was man dabei braucht. Unterschiede zwischen einem Hub & Router ,Switch. Probleme mit dem Routern, die nicht optimal eingestellt sind. http://public.fh-wolfenbuettel.de/~haas/cmsFiles/Feldbusse/EthernetTCPIPNeu/Lokale%20Netze%20(LAN)%20auf%20der%20Basis%20von%20Ethernet%20und%20TCP-IP,%20Tutorial%20von%20Wolfgang%20Loesch.htm Ganz weit unten der Artikel: Auto-Negotiation Zitat: Da es häufig zu Problemen führt, wenn der eine Kommunikationspartner fest eingestellt ist und der andere mit Auto-Negotiation arbeitet, sollte man beide Kommunikationspartner entweder mit Auto-Negotiation betreiben (falls beide dies unterstützen) oder beide fest einstellen. Wenn in einem Netz (Repeating-)Hubs, Repeater oder Konverter, die prinzipiell nicht voll-duplex-fähig sind, oder Datenendgeräte mit nicht voll-duplex-fähigen Netzkwerkadaptern eingesetzt werden, ist besondere Vorsicht geboten, da der Mischbetrieb von nur halb-duplex-fähigen Netzkomponenten mit voll-duplex-fähigen Netzkomponenten mit Auto-Negotiation zu unvorhersehbaren Schwierigkeiten führen kann. Gruss Holger.
Trundle Trollkönig schrieb: > konkret Rene für Hardware-Ethernet brauchst du: > > - Gmii-Interface > - Analysemodul für die ankommenden Pakete : Layer 2 und Layer 3 (OSI) > - und wenn du UDP als Protokoll verwenden willst, brauchst nen Modul was > folgende Protokolle beherrscht, dir also entsprechende Antwortpakete > schnüren kann: > - ARP-Pakete > - ICMP-Pakete > - UDP-Pakete Ja aber erst mal das einfach als LoopBack testen. Hier einfach IP address 127.0.0.1 verwenden. Damit ist das TX via RX duch den Switch durchgereicht. Zitat: Definition: The IP address 127.0.0.1 is a special purpose address reserved for use on each computer. 127.0.0.1 is conventionally a computer's loopback address. Network software and utilities can use 127.0.0.1 to access a local computer's TCP/IP network resources. Messages sent to loopback IP addresses like 127.0.0.1 do not reach outside to the local area network (LAN) but instead are automatically re-routed by the computer's own network adapter back to the receiving end of the TCP/IP stack. Typically all IP addresses in the range 127.0.0.1 - 127.255.255.255 are reserved for private use, but 127.0.0.1 is by convention the loopback address in almost all cases. Gruss Holger.
Angehängte Dateien:
-
MAC_1.PNG
300 KB
Hallo René D. ! Anhang Bild von einem fetigen MAC mit int. PHY +MII Inteface. MAC_1.PNG. Anhang Datenblatt zum PHY von SMSC Typ: LAN83c185, leider ist das MII Register nicht so gut erklärt, oder ich habe da was übersehen. http://www.mikrocontroller.net/attachment/199992/83c185.pdf René D. schrieb: > Genau so will ich es machen. Die CRC32 checkt bereits die Phy? Der Phy macht erst mal kein CRC. Da ist zB das NRZ 8B/10B drin, und noch einiges an Flags, usw. advanced ( Differential Bus Transceiver) Hier bei dem PHY von ICS1893 von Integrated Circuit Systems, Inc ist das ganz gut offengelegt, wie man mit dem Iterface RMII, und MII umgeht. Das MII ist ein bidir Inteface das z.B den Loopback einstellt. Dazu mus aber "immer" zuerst mal ein Command Override Write Enable Register beschrieben werden, damit folgend der z.B LoopBack parameter gesetzt wird. > Kann die Marvell88E1111 das auch? Der Marvell 88E1111 NSA ist nicht so offengelegt. (NDA-worthy) National Semi DP83865 Gigabit Ethernet PHY chip. LAN83c185 MII Interface -------------- ICS1893 Integrated Circuit Systems, Inc. Chapter 8 Management Register Set 8.11.1 Command Override Write Enable (bit 16.15) The Command Override Write Enable bit provides an STA the ability to alter the Command Override Write (CW) bits located throughout the MII Register set. A two-step process is required to alter the value of a CW bit: 1. Step one is to issue a Command Override Write, (that is, set bit 16.15 to logic one). This step enables the next MDIO write to have the ability to alter any CW bit. 2. Step two is to write to the register that includes the CW bit which requires modification. Note: The Command Override Write Enable bit is a Self-Clearing bit that is automatically reset to logic zero after the next MII write, thereby allowing only one subsequent write to alter the CW bits in a single register. To alter additional CW bits, the Command Override Write Enable bit must once again be set to logic one. Gruss Holger.
Angehängte Dateien:
-
MII_interFace_1.PNG
68 KB
@ René D. Anhang Bild: MII_interFace_1.PNG Das ist aus dem http://www.mikrocontroller.net/attachment/199992/83c185.pdf Aber ich finde das Override Register da nicht. Oder ist der SMSC Typ: LAN83c185 ohne das Override Register erst zu schreiben, einfacher zu parametrieren ? Muss ich wohl noch mal lesen... Gruss Holger.
Das ist mit 200ns Bus response time .. Integrated Circuit Systems, Inc Rapid I/O http://www.idt.com/products/interface-connectivity/serial-rapidio-solutions Protokolle sind auch mit dabei. https://www.youtube.com/watch?feature=player_embedded&v=IilIWos4EgE Gruss Holger.
Ich bin dran es mit UDP zurealisieren. Momentan habe ich ein Problem mit der Checksumme im IP4. Wie die Checksumme berechnet wird, ist mir schon klar. Nur wird die Checksumme im IPheader mit gesendt, und diese ist nicht an der letzten Position. Es gehen noch Daten in die Berechung ein, die später folgen. Da ist nicht lustig, hier muss ich noch was umschmeißen.
Roger Steiner schrieb: > Im IPV4 UDP ist die Checksumme optional. Es gibt zwei Checksummen. eine im IP4 und eine im UDP. Welche meinst du?
die im UDP, die hat dein Problem. Fuer die Checksumme im Header kannst du dir alles schon bereitlegen, die einzige Variable ist die Laenge.
Es werden beide Checksummen gebraucht. IP4 Checksumme ist über den IP header. Da kann ich alles bereitlegen. UDP Checksumme kann lauft Norm RFC auf Null gesetzt werden, dann ist die Checksumme disabled. Nur in der Praxis habe ich leide festgestellt, bei UDPChecksumme=0 schmeisst der Portmapper das Paket weg und kommt nicht bis zur Applikation durch. Ende vom Lied: UDPChecksumme ist notwendig >Fuer die Checksumme im Header kannst du dir alles schon bereitlegen, >die einzige Variable ist die Laenge. Falschmeldung Jetzt noch wie eine UDP Checksumme gebildet wird. Es wird ein Pseudoheader erzeugt und über diesen und das ganze Datagramm die Checksumme ermittelt. So sollen fehlgeleitete Paket erkannt werden.
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.