mikrocontroller.net

Forum: FPGA, VHDL & Co. Einsetzen einer CTRL-Funktion in Zynq


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.
Autor: Karli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: -gb- (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: VHDL hotline (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bastian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.