mikrocontroller.net

Forum: FPGA, VHDL & Co. Zynq - eigene Komponenten unter Linux


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich habe bisher nichts mit Zynq gemacht, aber so langsam werden die CPUs 
da drinnen ja angenehm schnell und können auch Video. Und das neue Board 
von Trenz reizt mich jetzt schon 
https://shop.trenz-electronic.de/de/TE0802-02-2AEU2-A-MPSoC-Development-Board-mit-Xilinx-Zynq-UltraScale-ZU2-und-LPDDR4?c=187 
.

Jedenfalls sieht meine derzeitige Lösung für eine Anwendung so aus:
Ich habe mehrere ADCs die hängen an FPGAs und die machen Dinge und raus 
fallen dann Messdaten über UART.
An einem PC hängen dann mehrere dieser UARTs die ich getrennt 
voneinander öffenen kann um messungen zu starten und die ich auch 
getrennt entfernen kann.

Jetzt möchte ich die ADCs direkt an den Zynq hängen, das was bisher im 
FPGA lief passt locker in den FPGA-Teil des Zynq und das was bisher auf 
dem Rechner lief, also ein Ubuntu mit GUI zur Messsteuerung und 
Aufzeichnung der Messwerte und Netzwerk zum wegschaufeln aufs NAS sollte 
mittlerweile auch auf den ARM Kernen laufen können.

Aber bevor ich damit anfange ist eben die Frage wie ich meine FPGA-Logik 
an die ARMs anschließe. Wie ist das, ist das nur ein Interface oder kann 
ich das auch aufteilen in mehrere Interfaces die dann unter dem Linux z. 
B. wie UARTs als /dev/TTYS0 bis /dev/TTYS3 auftauchen?
Vom FPGA kommen mehrere Datenströme die nichts miteinander zu tun haben 
und unter Linux von unterschiedlichen Programmen empfangen werden. Daher 
sollten das dann auch am besten unterschiedliche "Geräte" sein.
Und was sind das für "Geräte"? Ich bediene derzeit unter Linux eben 
UARTs, das geht sehr einfach mit Python. Kann man da auch virtuelle 
UARTs an die ARM Kerne anschließen die also zwischen FPGA-Teil und 
ARM-Teil als UART funktionieren?

Vielen Dank!

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Aber bevor ich damit anfange ist eben die Frage wie ich meine FPGA-Logik
> an die ARMs anschließe.

AXI

Gustl B. schrieb:
> Kann man da auch virtuelle
> UARTs an die ARM Kerne anschließen die also zwischen FPGA-Teil und
> ARM-Teil als UART funktionieren?

Könnte man schon. Erscheint mir aber als nicht so schöne Lösung. Klar, 
in deinem Fall würde das den Portierungsaufwand sehr überschaubar halten 
und die Software bleibt kompatibel zum jetzigen Aufbau.

Das Xilinx UG1165 "Zynq-7000 All Programmable SoC: Embedded Design 
Tutorial
A Hands-On Guide to Effective Embedded System Design" baut in Kapitel 7 
einen custom IP core mit passendem Linux Kernelmodul und setzt den in 
ein Linux Gesammtsystem.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Danke!
Gut, AXI habe ich schon verwendet, ist jetzt nicht sehr kompiziert da 
eigene Hardware manuell ranzubasteln. Aber mich interessiert wie das 
dann im Linux funktioniert. Wie einfach ist das da mit Python draus zu 
lesen?

UART mit Python ist eben sehr sehr einfach und wenn das mit AXI deutlich 
komplizierter würde dann bleibe ich einfach bei der aktuellen Lösung. 
Ich habe ja keinen Umzugszwang. Ist eher zum Spielen gedacht.

von Hannes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Im einfachsten Fall kannst du dein AXI-Device einfach aus /dev/mem 
mmapen (root vorausgesetzt). Damit gehen aber nur einfache Transfers, 
fuer so Sachen wie Interrupts brauchst du zumindest einen kleinen 
Treiber.

Ein recht einfacher Einstieg dafuer kann aber schon sowas wie die 
UIO-Treiber 
(https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842490/Testing+UIO+with+Interrupt+on+Zynq+Ultrascale) 
sein.

Falls schwierigere Sachen gebraucht werden (Dauerhaftes Streaming, hohe 
Bandbreiten, Cache-Koherenz) wirst du wohl kaum um einen richtigen 
Treiber herumkommen.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Ich brauche nur eine geringe Datenrate und möchte eben komplett ohne 
Handshake einfach schreiben und lesen können. Wie UART eben.

von P.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das hier könnte vielleicht hilfreich sein:

https://github.com/RedPitaya/RedPitaya

von Hans-Georg L. (h-g-l)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt von Digilent PMODs mit UART lies dich da mal durch die Doku.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Wie ein UART geht weiß ich. Aber ich will ja keinen echten UART, sondern 
eine einfach zu bedienende Schittstelle zwischen FPGA und CPU im Zynq. 
Und zwar einfach aus Python heraus und nicht nur eine, sondern 
mindestens 4 gleichzeitig die völlig voneinander getrennt sind.

Das voneinander getrennt möchte ich, weil ich da mit mehreren Programmen 
gleichzeitig drauf zugreifen will. Und zwar über lange Zeit. Die 
Messungen dauern oft mehrere Wochen. Es laufen auch oft mehrere 
Messungen gleichzeitig. Wenn ich dann also meine Software gegen eine 
andere Version austausche oder so, dann will ich nicht alle Messungen 
beenden müssen, sondern immer dann wenn sowieso eine zu Ende ist nur 
dort an der jeweiligen Schnittstelle mit einer neuen Software eine neue 
Messung starten. Mit UARTs klappt das sehr zuverlässig und wenn man eine 
geeignete Software baut, dann läuft die auch mal ein halbes Jahr ohne 
Fehler.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Aber mich interessiert wie das dann im Linux funktioniert.
> Wie einfach ist das da mit Python draus zu lesen?

Das hängt davon ab, wie du die Treiberstruktur im Linux einbindest. In 
jedem Fall musst du den Devicetree um dein "Gerät" erweitern, und da 
trägst du auch die verwendeten Ressourcen ein (Adressraum, Interrupts, 
etc.)

Wenn du den UIO-Treiber benutzt, dann greifst du auf das Gerät über eine 
Datei /dev/uioN zu, mittels mmap(). Außerdem brauchst du ein bisschen 
Informationen aus dem sysfs. Mit Python ist das alles möglich, da beides 
(Dateien öffnen und mmap()) implementiert sind.

Wenn du einen anderen Kerneltreiber nutzen willst (z.B. eine UART), dann 
muss deine Hardware dazu kompatibel sein. Es gibt aber hinreichend 
einfach gestrickte Hardware für sowas. In dem Augenblick bekommst du 
dann ein /dev/ttyDing, was du mit den normalen UART-Bibliotheken 
ansprechen kannst.

Hängt halt davon ab, was du genau brauchst. Ich würde mit dem 
UIO-Framework anfangen und schauen, ob das ausreicht. Das ist maximal 
flexibel, dafür schreibst du halt deinen Treiber im Userspace (z.B. in 
Python) selbst und kannst keine andere Software damit benutzen.

von Hans-Georg L. (h-g-l)


Bewertung
0 lesenswert
nicht lesenswert
Wenn die Uarts an einen PMOD am FPGA angeschlossen werden müssen die ja 
auch durch das FPAGA zum Prozessor geroutet werden. Bei Digilent gibt es 
üblicherweise den Code, den solltest du dir anschauen wie die es gemacht 
haben.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Und zwar einfach aus Python heraus und nicht nur eine, sondern
> mindestens 4 gleichzeitig die völlig voneinander getrennt sind.

Niemand hindert dich, 4 Geräte an den AXI zu klemmen und dann 4 Nodes im 
Device-Tree einzubauen. Dann bekommst du halt /dev/uio0 bis /dev/uio3.

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Hans-Georg L. schrieb:
> Wenn die Uarts an einen PMOD am FPGA angeschlossen werden müssen die ja
> auch durch das FPAGA zum Prozessor geroutet werden. Bei Digilent gibt es
> üblicherweise den Code, den solltest du dir anschauen wie die es gemacht
> haben.

Der taucht auch als UART im Linux auf? Sehr schick!

Alles klar, dann habe ich noch eine letzte Frage:
Kann man das simulieren? Also komplett mit Linux? Wohl eher nicht, ich 
muss also zuerst shoppen gehen ...

von Fitzebutze (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Alles klar, dann habe ich noch eine letzte Frage:
> Kann man das simulieren? Also komplett mit Linux? Wohl eher nicht, ich
> muss also zuerst shoppen gehen ...

Man kann, aber es ist entweder ziemlich teuer, oder ziemlich aufwendig 
zu stricken, d.h. entweder leistet man sich ein Tool von Cadence usw. 
oder hilft sich mit qemu und Co-Simulations-Interfacing und baut seine 
Hardwarekonstellation nach.
Für RiscV gibt es da etwas mehr Auswahl an 'fertigeren' Simulatoren, die 
unterstützen für die HW allerdings wieder nur Verilog.

Und mit zyklengenau ist vorbei, d.h. Timing lässt sich allenfalls nicht 
exakt simulieren und genau da wird es knifflig, wenn Software-Timeouts 
im Spiel sind (die HW läuft ja viele 1000 mal langsamer als in echt)
Muss man also im Kopf behalten, dass man auch den Timer über die 
HW-Seite emuliert.

von Hans-Georg L. (h-g-l)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe es selbst noch nicht probiert und du musst nicht shoppen gehen 
;-) Nur den Code runter laden und ankucken.

Vergiss es geht scheinbar einfacher direkt mit Vivado IP Cores:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842080/AXI+UART+16550+standalone+driver

Habe gerade mal in Vivado 2015.2 nachgeguckt ..
Findest du bei den IP Cores
-> embedded processing
-> AXI Peripheral
-> Low Speed peripheral
-> AXI UART 16550 (License included)

Und den kennnt Linux mit Sicherheit;-)

: Bearbeitet durch User
von daniel__m (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hi,

wie schön öfters angedeutet, die einfachste Lösung ist die:

Nimm den Zynq, füge in der PL n-mal den Xilinx UART ein (16550 oder den 
kleineren UartLite). Diese per Interconenct an den Zynq bzw. rx/tx an 
deine bestehende Module. Das solte alles sein. Danach bauen lassen 
(inkl. Devicetree) und in Linux sollten n-mal zusätzliche Uarts 
auftauchen. Deine SW solltest du garnicht anpassen müssen (es sei denn 
die Uarts sind hardcodiert).

grüße

von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
verstehe ich das richtig? 
Zynq->UartIP->Uart-TX-Leitung>eigenes_FPGA-Modul?

Ist der Linux-Treiber wirklich so schlimm, dass man keinen 
GPIO-Controller nehmen kann? Da hat man immerhin gleich 32bit parallel.

von Hans-Georg L. (h-g-l)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Hallo,
> ich habe bisher nichts mit Zynq gemacht, aber so langsam werden die CPUs
> da drinnen ja angenehm schnell und können auch Video. Und das neue Board
> von Trenz reizt mich jetzt schon
> 
https://shop.trenz-electronic.de/de/TE0802-02-2AEU2-A-MPSoC-Development-Board-mit-Xilinx-Zynq-UltraScale-ZU2-und-LPDDR4?c=187

Wenn dir die 16 IO Pins  und die Übertragungsraten von PMOD für deine AD 
Wandler reichen ...

Sonst such dir eines mit FMC.

von Hans-Georg L. (h-g-l)


Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> verstehe ich das richtig?
> Zynq->UartIP->Uart-TX-Leitung>eigenes_FPGA-Modul?
>
> Ist der Linux-Treiber wirklich so schlimm, dass man keinen
> GPIO-Controller nehmen kann? Da hat man immerhin gleich 32bit parallel.

So wie ich es verstanden habe ...

Der Fpga Teil vom Zynq soll das bisherige FPGA Board ersetzten und die 
"interne" Anbindung an Linux wie bisher über UART gemacht werden.

von Videomann (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Und das neue Board
> von Trenz reizt mich jetzt schon

das dortige VGA und der DP sind beides Ausgänge, oder?

von Gustl B. (-gb-)


Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank nochmal, also gehe ich shoppen und versuche es mit den AXI 
UARTs. Ja, 16 IOs reichen mir, das sind 4 ADCs in einem Stein der über 
SPI angesprochen wird. Eigentlich reichen dafür sogar nur 7 IOs,
SCLK
#CNV
SDO1 ... SDO 4
CLKOUT.

Ja, auf dem Board sind VGA und DP nur Ausgänge. Aber das reicht mir. Es 
soll da eben ein Linux Desktop laufen mit den üblichen Programmen 
(Filemanager, Terminal, ...) und eben mehrere Pythonprogramme mit GUI.

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Der taucht auch als UART im Linux auf? Sehr schick!
Nur wenn man auch den entsprechnden Core im devicetree bekannt gibt.

Duke

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.