Forum: FPGA, VHDL & Co. Ethernet <-> PC Smartfusion2


von Chris (Gast)


Lesenswert?

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?

von Duke Scarring (Gast)


Lesenswert?

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

von Chris (Gast)


Lesenswert?

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!

von Lars R. (lrs)


Lesenswert?

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

von Chris (Gast)


Lesenswert?

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?

von Lars R. (lrs)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Lars R. (lrs)


Lesenswert?

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.

von Duke Scarring (Gast)


Lesenswert?

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

von Lars R. (lrs)


Lesenswert?

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

von Duke Scarring (Gast)


Angehängte Dateien:

Lesenswert?

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

von Lars R. (lrs)


Lesenswert?

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

Welche verwendest Du?

Danke, Lars.

von Chris (Gast)


Lesenswert?

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?

von Lars R. (lrs)


Lesenswert?

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
von Duke Scarring (Gast)


Lesenswert?

Lars R. schrieb:
> Welche verwendest Du?
Die ZPU [1].

Duke

[1] https://github.com/zylin/zpu

von Chris (Gast)


Lesenswert?

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?

von Lars R. (lrs)


Angehängte Dateien:

Lesenswert?

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
von Chris (Gast)


Angehängte Dateien:

Lesenswert?

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?

von Lars R. (lrs)


Lesenswert?

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.

von Chris (Gast)


Lesenswert?

Danke ich werde es mal ausprobieren :)

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
Noch kein Account? Hier anmelden.