Ethernet <-> PC Smartfusion2

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...

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.

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.

? 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.

Duke Scarring schrieb:
> von einer schmalbrüstigen Soft-CPU (50
> MHz) gehandelt.

Welche verwendest Du?

Danke, Lars.

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.

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.

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.