Hallo zusammen, ich habe mir ein Smartfusion2 Starter Kit von Emcraft gekauft, um ein bisschen Erfahrung mit den FPGA's zusammeln. Ich wollte würde gerne Daten über die Ethernet-Schnittstelle zum FPGA senden/empfangen. Leider habe ich keien Erfahrung in dieser Richtung und es gibt auch für dieses Board kein Tutorial. Jetzt wollte ich fragen, ob jemand mit diesem Board schon einmal Daten versendet bzw. empfangen hat?
Chris schrieb: > Jetzt wollte ich fragen, ob > jemand mit diesem Board schon einmal Daten versendet bzw. empfangen hat? Ein Link zum Datenblatt wäre ganz hilfreich gewesen... Meinst Du dieses Board? http://www.emcraft.com/products/255 Da ist ein PHY drauf. Der ist wohl nicht zur Zierde eindesignt worden... Duke
Hallo Duke, genau das ist das Board. Mein Problem ist es, wie muss ich die Daten versenden? Muss ich ein UDP Protokoll programmieren, oder brauch ich das nicht? Und muss ich es in dem SoC programmieren? Sorry für solche Fragen, aber ich befasse mich erst damit!
Der SF2 hat einen Cortex M3. Mit Libero SoC kann ein Design erstellt werden, welches den Cortex M3 beinhaltet. Inzwischen ist dieser Vorgang im Rahmen der Erstellung eines neuen Projektes als graphischer Flow gestaltet (SystemBuilder). Die MSS-Komponente muss so konfiguriert werden, dass Ethernet-MAC und Uart aktiviert sind. Dann werden die erforderlichen Pins automatisch ganz heraus geführt. Natürlich muss auch clock und reset passend zum Board eingestellt werden. Anschließend kann das FPGA-Design vollständig erstellt werden, und zwar hoffentlich fehlerfrei. Weiterhin kann in Libero SoC eine Firmware-Konfiguration erstellt werden. Hierbei kann man UART und Ethernet-MAC entsprechend der MSS-Konfiguration explizit auswählen. Die MAC-Komponente kann konfiguriert werden. Hierbei ist die PHY des EMCRAFT-Kits aus dem Dropdown-Menü auszuwählen. Ebenso können verschiedene Templates/Usecase-Examples für jede Komponente erzeugt werden. Diese werden aber nicht zwangsläufig als aktuelles SW-Projekt erstellt, sondern die Dateien befinden sich dann in Unterverzeichnissen. Hinsichtlich der SW-Entwicklung werden verschiedene SW-Umgebungen unterstützt. Es bietet sich an, Softconsole zu nutzen, denn Softconsole ist Bestandteil des Microsemi-Programmpacketes; zumindest in der Windows-Version. Softconsole ist Eclipse-basiert. Das Software-Projekt kann über den Designflow links unten geöffnet werden. Von nun an findet eine typische cmsis-Entwicklung statt: Status von MAC und PHY können abgefragt und gesetzt werden. Die Software wird dann kompiliert und per Debug auf den ARM-SRAM geladen und ausgeführt. In den Nvram muss zu diesem Zeitpunkt noch nichts geschrieben werden. Es kann ein MAC-Packet, beinhaltend ein UDP-Packet, erstellt und abgeschickt werden. Am PC kann dieses Packet mit Wireshark beobachtet werden. Dabei sind ein paar Fallstricke zu beachten, insbesondere: Ab wann akzeptiert Windows welches MAC-Packet von welcher MAC? Wichtig ist es beispielsweise, nach dem "Starten" der Software einen Moment mit dem Absenden des Packetes zu warten, denn nach der Initalisierung dauert es ggf. einen Moment, bis die Ethernetverbindung auf IP-Ebene als established gilt. Es bietet sich an, den Design-Flow zunächst ohne Ethernet mit dem UART zu erlernen und zu üben. Ein IP-Stack (beispielsweise) lwip oder ein ganzes OS ( a. http://www.freertos.org/SmartFusion2_RTOS.html b. Linux von emcraft c. ... ) kann auch genutzt werden. In jedem Fall ist die Ethernet-MAC eine Komponente des ARM-MSS. Möchte man vom FPGA-FABRIC aus (LUTs) Daten über Ethernet verschicken, so müssen dafür die Interfaces FABRIC<->MSS genutzt werden. Prinzipiell stehen AHB und APB zur Verfügung, oder auch AXI. Das Ganze kann man auch so gestalten, dass der Vorgang ohne wesentliche Zuarbeit des Cortex-M3 statt findet und dieser für andere Aufgaben verwendet wird. Selbst die DMA-Controller des ARM-MSS müssen nicht unbedingt genutzt werden, falls das FPGA-FABRIC-Design als AHB-Master die Daten selbst in den Speicher schreibt. ...oder konnte sogar die Ethernet-MAC als Master die Daten selbst von einem FPGA-FABRIC-Slave abholen?... Naja, das ist dann schon recht speziell...
Hallo Lars, vielen Dank für deine sehr ausführliche Beschreibung. Diese wird mir sehr weiterhelfen. Ich werde es mal mit der SoftConsole ausprobieren. Ich hätte noch eine Frage bzgl. dem OS. Welche Vorteile hat das Linux System von Emcraft? Ist es besser das zu verwenden? Hast du damit schon Erfahrungen gemacht?
Chris schrieb: > Welche Vorteile hat das Linux > System von Emcraft? Es ist ein out-of-the-box-lauffähiges System mit einem gewissen Level an Support, der sich tendenziell jedoch nicht auf uCLinux ganz allgemein, sondern eher auf die emcraft-produktspezifischen Eigenschafen konzentriert. > Ist es besser das zu verwenden? Das kommt auf den Anwendungsfall an. > Hast du damit schon > Erfahrungen gemacht? Wahrscheinlich ja, es ist schon etwas her. Es ist eben ein uclinux.
Chris schrieb: > genau das ist das Board. Gibt es da noch ein Trägerboard dazu? Auf dem Ding ist zwar ein PHY aber noch keine RJ45-Buchse drauf. > Mein Problem ist es, wie muss ich die Daten > versenden? Muss ich ein UDP Protokoll programmieren, oder brauch ich das > nicht? Das kommt darauf an. Vor der UDP-Realisierung kommen noch IP, ICMP, ARP und die Ethernet-Frames. > Und muss ich es in dem SoC programmieren? Ich kenn das Ding nicht. Wenn die Signal vom PHY (nur) an den SOC gehen, dann sollte man besser diesen auch nehmen. Duke
Duke Scarring schrieb: > Chris schrieb: >> genau das ist das Board. > Gibt es da noch ein Trägerboard dazu? > Auf dem Ding ist zwar ein PHY aber noch keine RJ45-Buchse drauf. http://www.emcraft.com/products/255#starter-kit Nach unten scrollen. >> Mein Problem ist es, wie muss ich die Daten >> versenden? Muss ich ein UDP Protokoll programmieren, oder brauch ich das >> nicht? > Das kommt darauf an. Vor der UDP-Realisierung kommen noch IP, ICMP, ARP > und die Ethernet-Frames. Zuvor kommt die Initialisierung von MAC und PHY. ICMP und ARP benötigt man hingegen für das Versenden eines UDP-Paketes nicht. Sind auch nicht hilfreich, falls es um hohe Performanz oder Realtime geht. MAC, IP und Zielport des PCs können "fest" in das UDP-Paket kodiert werden. Falls man ICMP, ARP und weitere (DHCP, DNS...) jedoch benötigt, so würde ich einen IP-Stack oder ein OS nutzen oder ein WIZNET-Modul anbinden. >> Und muss ich es in dem SoC programmieren? > Ich kenn das Ding nicht. Wenn die Signal vom PHY (nur) an den SOC gehen, > dann sollte man besser diesen auch nehmen. Die vorhandene MAC sitzt in der ARM-Komponente. Man kann aber einen HDL-Interfacekonverter dazwischen hängen (zB RMII<-> MII) oder seine eine eigene MAC in HDL nutzen.
Lars R. schrieb: > ICMP und ARP benötigt > man hingegen für das Versenden eines UDP-Paketes nicht. Das ist prinzipiell richtig. Aber damit sich das Ding auch ein bissel wie Netzwerk anfühlt, hilft es, wenn ein Host die richtige MAC-Adresse ermitteln kann (ARP) und die Schnittstelle auf einen Ping (ICMP) reagiert. > Sind auch nicht > hilfreich, falls es um hohe Performanz oder Realtime geht. Das sehe ich nicht so. Es stört doch nicht, wenn auf ARP-Request und auf ICMP-Echo-Request reagiert werden kann. Duke
? bissel wie Netzwerk anfühlt Wenn diese Gefühle den zusätzlichen Entwicklungsaufwand und Performanzverlust wert sind, dann ist es gut. So ein Cortex M3 166MHz ist schon ein wenig ausgelastet, wenn er jedes Ethernetpaket mit einem IP-Stack bearbeitet und ggf beantwortet; insbesondere dann, wenn er an einer geschwätzigen Windows-Maschine betrieben wird. Wenn das ok ist, dann ist es gut. Es stellt sich nur die Frage, warum man sich überhaupt damit befasst, anstatt eine günstigere, fertige Lösung zu verwenden. Security als Anforderung rechtfertigt natürlich vieles bzw erfordert vieles. Das Schreiben eines eigenen IP-Stacks halte ich für noch weniger sinnvoll, bzw. sollten die Projektanforderungen noch spezifischer sein, um den Aufwand zu rechtfertigen. Dann befasst man sich immer weniger mit FPGA und ARM, und immer mehr mit Ethernet-Standards und Abweichungen davon.
Lars R. schrieb: > Wenn diese Gefühle den zusätzlichen Entwicklungsaufwand und > Performanzverlust wert sind, dann ist es gut. Na es geht ja nicht nur um Gefühl, sondern auch um Nutzbarkeit. Und wenn ich mehrere FPGA-Slaves im Netzwerk habe (und das ist ein Grund, warum man Netzwerk haben will), dann brauche ich auch Debugging, damit ich weiß, ob es am Netzwerk klemmt oder an einer anderen Stelle. > So ein Cortex M3 166MHz ist schon ein wenig ausgelastet, wenn er jedes > Ethernetpaket mit einem IP-Stack bearbeitet und ggf beantwortet; > insbesondere dann, wenn er an einer geschwätzigen Windows-Maschine > betrieben wird. Das ist richtig. Ich schalte da auch erstmal allen Kram ab, soweit das geht. Außerdem läuft bei mir der Ethernetstack komplett in Hardware (inkl. ARP und ICMP) oder der Traffik wird von einer schmalbrüstigen Soft-CPU (50 MHz) gehandelt. Wenn letzters der Fall ist, gibt es response-Zeiten im ms-Bereich.
1 | $ ping 192.168.1.1 |
2 | |
3 | Ping wird ausgeführt für 192.168.1.1 mit 32 Bytes Daten: |
4 | Antwort von 192.168.1.1: Bytes=32 Zeit=1ms TTL=255 |
5 | Antwort von 192.168.1.1: Bytes=32 Zeit=1ms TTL=255 |
6 | Antwort von 192.168.1.1: Bytes=32 Zeit=1ms TTL=255 |
7 | Antwort von 192.168.1.1: Bytes=32 Zeit=1ms TTL=255 |
8 | |
9 | Ping-Statistik für 192.168.1.1: |
10 | Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 |
11 | (0% Verlust), |
12 | Ca. Zeitangaben in Millisek.: |
13 | Minimum = 1ms, Maximum = 1ms, Mittelwert = 1ms |
14 | |
15 | |
16 | $ ping 192.168.1.1 -l 1024 |
17 | |
18 | Ping wird ausgeführt für 192.168.1.1 mit 1024 Bytes Daten: |
19 | Antwort von 192.168.1.1: Bytes=1024 Zeit=11ms TTL=255 |
20 | Antwort von 192.168.1.1: Bytes=1024 Zeit=12ms TTL=255 |
21 | Antwort von 192.168.1.1: Bytes=1024 Zeit=12ms TTL=255 |
22 | Antwort von 192.168.1.1: Bytes=1024 Zeit=12ms TTL=255 |
23 | |
24 | Ping-Statistik für 192.168.1.1: |
25 | Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 |
26 | (0% Verlust), |
27 | Ca. Zeitangaben in Millisek.: |
28 | Minimum = 11ms, Maximum = 12ms, Mittelwert = 11ms |
Duke
Duke Scarring schrieb: > von einer schmalbrüstigen Soft-CPU (50 > MHz) gehandelt. Welche verwendest Du? Danke, Lars.
Wenn ich jetzt z.B. das OS uClinux verwenden möchte, benötige ich dann auf dem Mikrocontroller ein Socket oder wie wird es dann gemacht?
Chris schrieb: > Wenn ich jetzt z.B. das OS uClinux verwenden möchte, benötige ich dann > auf dem Mikrocontroller ein Socket oder wie wird es dann gemacht? Ja. Bisher habe ich nicht den Eindruck, dass der Smartfusion2 eine geeignete Plattform für Dich ist. Hast Du Dich aus einem bestimmten Grund dafür entschieden und was ist Dein Ziel? Als Orientierung kann man im Forum Fragen stellen und sehr gern kannst Du auch weiter fragen. Nur weiter kommen wirst Du damit von Deinem jetzigen Stand aus nicht, zumal es sich nicht um Detailfragen handelt.
:
Bearbeitet durch User
Lars R. schrieb: > Chris schrieb: >> Wenn ich jetzt z.B. das OS uClinux verwenden möchte, benötige ich dann >> auf dem Mikrocontroller ein Socket oder wie wird es dann gemacht? > > Ja. > > Bisher habe ich nicht den Eindruck, dass der Smartfusion2 eine geeignete > Plattform für Dich ist. Hast Du Dich aus einem bestimmten Grund dafür > entschieden und was ist Dein Ziel? Als Orientierung kann man im Forum > Fragen stellen und sehr gern kannst Du auch weiter fragen. Nur weiter > kommen wirst Du damit von Deinem jetzigen Stand aus nicht, zumal es sich > nicht um Detailfragen handelt. Ich habe diese Vorlesung nächstes Semester und wollte schon einmal jetzt mich bisschen damit befassen. Im Moment ist es nur Hobby für mich :). Ich habe so wie du es am Anfang geschrieben hast zuerst mal mit UART ausprobiert. Damit kann ich jetzt auch Message von der SoftConsole auf die Console ausgeben. Jedoch würde ich gerne einen Wert in die Console schreiben und diesen dann an das MSS schicken und dann an die FABRIC. Ich habe es bis zur SoftConsole geschafft, jedoch weiß ich nicht wie ich jetzt von der Softconsole zur FABRIC komme? Bis jetzt habe ich beim FIC_0 einen AHB_Master und dieser geht nun auf ein CoreAHBlite. Jedoch weiß ich jetzt nicht weiter ;) Könntest du mir dabei nochmals behilflich sein?
Du hast eine Vorlesung mit dem Themenschwerpunkt Smartfusion2? Wo? Bzgl der Busssysteme "möchtest" Du einen APB-Slave anbinden. Diesen musst Du HDL mit den APB-Ports schreiben und als Buskomponente deklarieren (rechtsklick auf HDL-File). Danach kannst Du das File als Buskomponente im grafischen Bereich instanziieren. Es erscheint dann ein Anschluss, an dem Du APB anschließen kannst. Über die entsprechenden Adressen (Einstellungen des Bus und auf was genau innerhalb des eingestellten Address-Bereiches Deine Komponente reagiert) kannst Du dann vom Cortex aus auf diese Adresse zugreifen. Anbei ein 8Bit-apb-Register mit 4 Speicherplätzen.
:
Bearbeitet durch User
Danke Lars für die Dateien. Ich werde es dies mal ausprobieren. Nein es gibt bei mir keine Vorlesung über Smartfusion2 nur über allgemein FPGA. Wie hast du dich in diese Thematik eingearbeitet? Hast du für mich irgendwelche Vorschläge? Kann man es auch so umsetzen, wie ich es im Anhang habe?
Chris schrieb: > Danke Lars für die Dateien. Ich werde es dies mal ausprobieren. Nein es > gibt bei mir keine Vorlesung über Smartfusion2 nur über allgemein FPGA. > Wie hast du dich in diese Thematik eingearbeitet? Schau mal auf die Homepage des Herstellers. > Hast du für mich > irgendwelche Vorschläge? Schenke mir oder jemand anderem das Kit, frage in der Uni nach, was genutzt werden wird und orientiere Dich daran. (Oder lege Deine wahre Identität offen.) > Kann man es auch so umsetzen, wie ich es im Anhang habe? Auf dem Bild sehe ich einen AHB-Slave-SRAM-Block. Statt einem fertigen Block (zB SRAM) möchtest Du jedoch eine eigene VHDL-Buskomponente anschließen. Statt APB kannst Du auch AHB verwenden. Dann muss Deine Komponente nicht APB, sondern AHB unterstützen. Das ist auch kein Problem. Aber es ist leichter, mit APB anzufangen.
Bitte 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.