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!
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.
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.
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.
Ich brauche nur eine geringe Datenrate und möchte eben komplett ohne Handshake einfach schreiben und lesen können. Wie UART eben.
Es gibt von Digilent PMODs mit UART lies dich da mal durch die Doku.
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.
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.
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.
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.
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 ...
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.
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
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
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.
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.
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.
Gustl B. schrieb: > Und das neue Board > von Trenz reizt mich jetzt schon das dortige VGA und der DP sind beides Ausgänge, oder?
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.
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
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.