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