Ich habe eine Controller-Anwendung, die auf einem Atmel lief. Diese soll nun in ein kompakteres System überführt werden. Als Beispiel wäre ein Zynq angedacht. Die Controller-Anwendung würde Software-seitig auf den MicroBlaze portiert (nehme ich an) und meinen Hardwareteil, der aus Zählern, Interrupt-Controllern und einer analogen Regelung besteht, müsste in den FPGA. Bevor der Aufschrei kommt: Die analoge Regelung kann durch einen ADC-DAC digital nachgebildet werden. Über bliebe eine VHDL. Die Kommunikation zwischen dem ATMEL und dem jetzigen Digitalteil wird mit einem PLD realisiert, der das digitale steuert und auch ein SRAM. Jetzt würde ich gerne wissen, wie ich das in einen FPGA bekomme: RAM wird es im FPGA genug geben, denke ich. Sind nur 4kB nötig. Muss ich das VHDL in einen AXI-Core verpacken, oder gibt es da eine andere Möglichkeit? Aus den Beispielen von Xilinx für ein Zynq-System sind GPIO ersichtlich. Kann ich die irgendwie intern nutzen? Der ATMEL greift über einen normalen Daten-Adress-Bus zu mit OE, WR, RD etc. und das würde ich gerne so lassen, ohne AXI Bus. Und wenn, sollte man das alles auch in der Grafik aufbauen, oder lieber ein eigenes Blöckchen in dem alle VHDL drin ist?
Bei dem Zynq ist ein Arm Kern dabei. Da brauchst du keinen microblaze. Du kannst aber auch auf den zynq verzichten, einen kleineren billigeren FPGA verwenden und dort einen Microblaze einbauen.
Karli schrieb: > Ich habe eine Controller-Anwendung, die auf einem Atmel lief. Auf einem 32 bit oder 8 Bit uC? Karli schrieb: > Als Beispiel wäre ein Zynq angedacht. Die Controller-Anwendung würde > Software-seitig auf den MicroBlaze portiert (nehme ich an) Wie schon gesagt brauchst du im Zynq den Microblaze nicht. Der Microblaze ist ein softcore und kann in (fast) jedem anderen Xilinx-FPGA eingebunden werden. Alternativ gibt es freie softcores, z.b. diverse RISC-V oder OpenRISC. Was du benutzen kannst und brauchst hängt von deiner Anwendnung ab. Ein Zynq klingt für etwas control ziemlich oversized, aber kann man natürlich machen. Karli schrieb: > Aus den Beispielen von Xilinx für ein Zynq-System sind GPIO ersichtlich. > Kann ich die irgendwie intern nutzen? Ja, die kannst du zum Großteil frei nutzen. Karli schrieb: > Und wenn, sollte man das alles auch in der Grafik aufbauen, oder lieber > ein eigenes Blöckchen in dem alle VHDL drin ist? Ich verstehe die Frage nicht.
Karli schrieb: > und meinen > Hardwareteil, der aus Zählern, Interrupt-Controllern und einer analogen > Regelung besteht, müsste in den FPGA. > > Bevor der Aufschrei kommt: Die analoge Regelung kann durch einen ADC-DAC > digital nachgebildet werden. Über bliebe eine VHDL. Die Frage ist: Ist ein FPGA hier wirklich erforderlich? Moderne Mikrocontroller sind ziemlich leistungsfähig und haben auch viel RAM (viel mehr als 4kB) und können auch einiges an Regelungen übernehmen. Das alles "klassisch" in Software zu implementieren könnte deutlich einfacher sein, wenn die Leistung/Latenz passt.
Der Zynq ist, wenn du vom Atmel her kommst, komplett 'überdosiert', und der Overhead beträchtlich. Macht nur Sinn, wenn du komplexere Anwendungen wie Linux, Network I/O usw. im Sinn hast. Du musst dich auf jeden Fall in den AXI/Amba-Kram reingraben, und dich mit der bare-metal-Initialisierung der CPU rumschlagen. Und du bist dann definitiv 'vendor locked'. Ob sich das rechnet? Ich weiss nicht, ob deine Anwendung ähnlich ist, aber für Safety-relevante PID-Regelungen (in beweisbarer HW) habe ich mir den SoC-Aufwasch in 'portabel' mit Soft-CPU usw. gegeben, das ganze System ist allerdings sehr Linux-zentrisch, siehe https://github.com/hackfin/masocist. Den Setup mit dem neo430 (msp430 kompatibel) kannst du out of the box virtuell in Docker-Container (so auch Web-Browser) laufen lassen. Für mehr Safety ist die ZPUng gedacht. Gibt dazu auch Hardware: https://hackaday.io/project/162259-netpp-node Die unterstützten Soft-Cores msp430 und ZPUng sind von der Code-Dichte her perfekt bei wenig BRAM. Der ganze Netzwerk-Stack und das 'OS' passt z.B. in 32 kB.
Karli schrieb: > Und wenn, sollte man das alles auch in der Grafik aufbauen, oder lieber > ein eigenes Blöckchen in dem alle VHDL drin ist? Ich verstehe die Frage so, dass Grafik umgangen werden soll. Dazu würde ich tunlichst raten. Xilinx hat die Angewohnheit immer wieder von Version zu Version kleine Dinge zu ändern, die ein upgraden inkompatibel und aufwändig macht. Daher werde ich es unterlassen, unnötig Funktionen, die kein AXI oder Interaktion mit der CPU brauchen, dort ausdrücklich einzuzeichnen. Auch generell sollte man nicht unnötige grafische Hierarchien verwenden, weil das in Änderbarkeit und Teamwork stören. Wir machen das so, dass es ein SoC-System gibt und einen PC-Teil, der in das FPGA geht und konventionell beschrieben wird. Das hat den Vorteil, dass es versionierbarer wird und teamfähiger / paralleler gebaut werden kann, ohne aufwändiges Einschecken und Branchen. Der PL-Teil ist als ein Block auch leicht isoliert vom Rest zu simulieren. Das ist in aller Regel auch sehr zielführend das getrennt zu tun, weil SoC-Teil und FPGA-Teil logischerweise völlig andere, meist komplementäre Dinge tun und sich andere inhaltliche Anforderungen an die Verfikation ergeben.
Weltbester FPGA-Pongo schrieb im Beitrag #5886727: > Ich verstehe die Frage so, dass Grafik umgangen werden soll. Dazu würde > ich tunlichst raten. Xilinx hat die Angewohnheit immer wieder von > Version zu Version kleine Dinge zu ändern, die ein upgraden inkompatibel > und aufwändig macht. Mein Rat: Grafisch erstmal soweit wie moeglich alles zusammenbauen was man haben moechte. Und wenn das Grundgeruest steht, daraus ein Tcl Skript machen, was man dann spaeter einfach bearbeiten und auch prima versionieren kann.
Ich habe vor längerer Zeit sowas mal gemacht. In Vivado ein Blockdesign (BD) erstellt, welches genau einen zusätzlichen Block enthält. Der spricht auf der einen Seite AXI, und enthält meine Logik, ist also effektiv das Top-Level-Design. Das gesamte Projekt wird über ein TCL-Script erstellt, dadurch kann sinnvoll versioniert werden. Auf Softwareseite habe ich schlicht Linux-UIO benutzt, d.h. im Devicetree die vergebenen Ressourcen für das AXI-Interface eingetragen (inklusive Interrupt). Ein C-Programm greift dann über /dev/uio0 auf das Design zu. Ein Softcore ist nur dann sinnvoll, wenn du schnell reagierende Echtzeit für den Controllerteil brauchst, ansonsten reicht das PS (also der ARM mit Linux) vollkommen aus.
S. R. schrieb: > Das gesamte > Projekt wird über ein TCL-Script erstellt, dadurch kann sinnvoll > versioniert werden. Versionieren ja, aber auch mit mehreren daran arbeiten und über Projektgrenzen updaten? Ich bin immer kritisch mit Block Designs und grafischen Malereien. >welches genau einen zusätzlichen Block enthält. Ja, so war es gemeint.
Weltbester FPGA-Pongo schrieb im Beitrag #5887774: > Versionieren ja, aber auch mit mehreren daran arbeiten Naja, das Problem beim Versionieren hast du immer wenn mehrere Leute gleichzeitig an einer Datei arbeiten sollen. Dann ist das Problem allerdings, dass das Projekt nicht ordentlich aufgeteilt ist. Tcl Skripte kannst du auch in mehere Teilskripte aufteilen, so koennen dann unterschiedliche Leute an unterschiedlichen Subsystemen arbeiten. In der Regel sollte das aber nicht noetig sein, da man genau einen System Architekten hat, der sich um das System als ganzes kuemmert. Wenn da mehrere dran rummfummeln wie jeder lustig ist, ohne seine Aenderungswuensche vom verantwortlichen Architekten absegnen zu lassen, kommst du nie ans Ziel.
:
Bearbeitet durch User
Weltbester FPGA-Pongo schrieb im Beitrag #5887774: >> Das gesamte Projekt wird über ein TCL-Script erstellt, >> dadurch kann sinnvoll versioniert werden. > > Versionieren ja, aber auch mit mehreren daran arbeiten > und über Projektgrenzen updaten? Als Doktorand war ich alleine beschäftigt ... > Ich bin immer kritisch mit Block Designs und grafischen Malereien. ... das gesamte Vivado-Projekt wird aus einem TCL-Script (genauer: einem Makefile, welches das TCL-Script aufruft) erstellt. Das heißt, dass der gesamte grafische Kram nie in der Versionierung landet. Mir ging es darum, ein reproduzierbares Projekt zu haben, wobei der gesamte restliche Code ausschließlich in Textform (TCL, VHDL, C) existiert. Ob man da mit mehreren dran arbeiten kann? Sicherlich. Über Projektgrenzen hinweg? Ich sehe irgendwie keinen Sinn darin, mehrere Projekte auf der Ebene unter einen Hut zu stellen. Wie gesagt, war ein Uniprojekt mit größeren Ambitionen und eher wenig Erfolg. Effektiv gab es auch keine Versionierung, sondern nur ordentliche Grundlagen dafür.
Karli schrieb: > Und wenn, sollte man das alles auch in der Grafik aufbauen, oder lieber > ein eigenes Blöckchen in dem alle VHDL drin ist? Ich kämpfe auch gerade mit dem Vivado und seinen grandiosen Grafiken. Leider kommt man nicht darum herum. Ich versuche aber, möglichst wenig davon zu nutzen und es so in Module zu verpacken, dass eine einmal angesetzte Grafik nicht mehr angefasst werden muss. Karli schrieb: > und das würde ich gerne > so lassen, ohne AXI Bus. Auch das geht. Ich benutze AXI nur, wo es nicht anders geht.
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.