Forum: FPGA, VHDL & Co. myhdl oder nmigen?


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 Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Für komplexere Systeme schaue ich mich immer wieder nach brauchbaren 
Frameworks um und stosse des öfteren auf Ansätze, mit Python Hardware zu 
generieren bzw designen. Da stehen insbesondere die Module nmigen und 
myhdl hervor. Meine Frage ist: Was davon kann man wirklich für 
langfristig angelegte Entwicklung brauchen? Bei myhdl scheint es eine 
ganze Latte an Conversions-Problemen zu geben, bei nmigen wiederum ist 
viel nicht dokumentiert und es liest sich deutlich weniger gut, usw. Von 
myhdl lese ich, dass es in der Entwicklung kaum weitergeht und keine 
neuen Features dazukommen (Kann auch was gutes sein, wenn sich nichts 
ändert)
Gibt es hier Experten, die damit regelmäßig arbeiten und dazu Tips geben 
können?

von Cyntia Cygnus (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Markus schrieb:
> Gibt es hier Experten, die damit regelmäßig arbeiten und dazu Tips geben
> können?

Ein Experte arbeitet nicht regelmäßig damit, ein Experte evaluiert das 
Ganze einmal, bewertet das zugrundeliegende Grundprinzip ("Hardware 
entwickeln ohne sich mit die Details von Hardware auseinanderzusetzen") 
und verwirft es dann als (für ihn als Experten) ungeeignet.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Markus schrieb:
> Ansätze, mit Python Hardware zu generieren bzw designen.
Das Problem daran ist das übliche: das verwenden dann 
Softwareprogrammierer, denen das Konzept von echter Parallelität in 
Hardware nicht geläufig ist. Und diese Softwareprogrammierer 
programmieren dann ihre sequentiellen Abläufe für diese Hardware so, wie 
sie es immer machen. Und das gibt dann halt extrem umständliche und 
überraschende Hardware.
Oder es gibt dann halt letztlich einen Prozessorkern, auf dem das 
Compilat abläuft.

Wenn man aber die Denkweise für das Hardwardesign drin hat, dann ist 
es schnurzegal, welche Sprache man für die Hardwarebeschreibung nimmt.

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Markus schrieb:
> Für komplexere Systeme schaue ich mich immer wieder nach brauchbaren
> Frameworks um und stosse des öfteren auf Ansätze, mit Python Hardware zu
> generieren bzw designen. Da stehen insbesondere die Module nmigen und
> myhdl hervor.

Framework? myhdl ist eher kein Framework.

> Bei myhdl scheint es eine
> ganze Latte an Conversions-Problemen zu geben

Mir sind nur wenige bekannt. Das meiste sind Notationsfehler. Mit den 
Freiheitsgraden von myhdl kann man noch viel mehr "Unsinn" hinschreiben 
als mit VHDL.

> Von
> myhdl lese ich, dass es in der Entwicklung kaum weitergeht und keine
> neuen Features dazukommen (Kann auch was gutes sein, wenn sich nichts
> ändert)

Ja, genau so ist das.

> Gibt es hier Experten, die damit regelmäßig arbeiten und dazu Tips geben
> können?

myhdl ist hardwarenah. Der Tipp von Lothar ist gut. myhdl nimmt Dir 
nicht die Denkarbeit ab.

Lothar M. schrieb:
> Wenn man aber die Denkweise für das Hardwardesign drin hat, dann ist
> es schnurzegal, welche Sprache man für die Hardwarebeschreibung nimmt.

Naja. "Interfaces", jetzt ganz neu in VHDL2019, gibt es in myhdl bereits 
eine ganze Weile; ebenso wie vieles andere, dass es voraussichtlich 
niemals in VHDL geben wird.

Gut, am Ende... mancherorts erzeugt man sich den VHDL-Code auch mit 
selbstgeschriebenem Python. Besser strukturiert, weniger 
Funktionsumfang.

myhdl ist nichts für Softwareprogrammierer.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und das gibt dann halt extrem umständliche und
> überraschende Hardware.
vereinzelt sogar sehr überraschend, vor allem überraschend viel ...

> Oder es gibt dann halt letztlich einen Prozessorkern, auf dem das
> Compilat abläuft.
meistens kommt eine verteckte, implizit realisierte Mimik heraus, die 
wie ein Prozessor arbeitet und dann voreingestellte Abläufe hintackert, 
so ein fest codiertes Schaltwerk.

Den Gipfel dieser Geschichte lieferte einst ein Physiker, der sich 
selber C++ beigebracht hat, die typischen Strukturen paralleler 
Verarbeitung in C++ und Betriebssystemen nicht kennt und dort bereits 
abenteuerliche Lösungen präsentiert hat und der dann die FPGAs entdeckt 
hat, die man ihm besser vorenthalten hätte.

Die Signalverarbeitungs-pipeline, die er programmiert hat, war bei 
genauerem Hinsehen eine doppelt verschachtelte Hardware, die so 
funktionierte, wie eine Software, welche eine Hardware nachstellt. Um es 
in einfachen Worten zu beschreiben, würde man bei einer Logikschaltung 
aus einigen UND- und ODER-Gattern mit FlipFlops diese in HW einfach 
aufbauen und optimieren lassen. Wollte man das in C nachbilden, braucht 
es ein kleines Programm, dass sich die Signale vor jedem Gatter holt, 
die Gatterfunktion dann ausführt und die Ergebnisse zwischenspeichert, 
um dann das nächste Gatter anzufassen, bis alle Ergebnisse stehen und 
das letzte ausgerechnet werden kann.

Unser Spezi hat nun eine FSM gebaut, die das komplett nachstellt, 
inklusive Speicher in BRAMs, Einschreibe- und Ausleseprozessen um die 
Ergebnisse und Inputs jedes "Gatters" (= VHDL Funktion) handhaben zu 
können und da in Realität statt der Gatter einiges zu rechnen war, lief 
das auch noch langsamer, als es ein richtiger Prozessor gemacht hätte.

Im Prinizip war es wie ein in Hardware gebauter ModelSIM, der alle 
Prozesse nacheinander abklappert und die Funktionen virtuell im Speicher 
behandelt, darin eingeschlossen die binären Signale als voll belegte 
Realvariable.

Hier haben gleich zwei Defizite zugeschlagen: Mangelnde Kenntnisse in 
Betriebssystemen und Methoden der Softwareentwicklung sowie mangelde 
Kenntnisse in digitaler Schaltungstechnik.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> myhdl ist hardwarenah. Der Tipp von Lothar ist gut. myhdl nimmt Dir
> nicht die Denkarbeit ab.

Es nimmt einem Tipparbeit ab, schränkt aber ein, denn eine ganze Reihe 
von Schaltungsstrukturen lassen sich da nicht gut beschreiben.

Was dabei herauskommen kann, zeigt das Beispiel, dass ich eins weiter 
oben beschrieben habe. Die meisten dieser Programme sind darauf 
ausgelegt, Schaltungsabläufe ausdrücklich zu übersetzen, d.h. eine 
Mechanik zu entwerfen, die den Ablauf kann. Damit das allgemein 
funktioniert, muss zwangsläufig eine programmierbare virtuelle HW bei 
rauskommen, die einem Prozessor ähnelt. Die ist aber immer langsam, weil 
sie nur einen Schritt von mehreren abarbeiten kann, während ein 
angepasstes Schaltwerk mehrere Dinge gleichzeitig tun kann.

Da die Abläufe und Rechenprozesse das eigentlich Aufwändige sind, macht 
das den größten Anteil des Ergebnisses aus. Der Rest ist ja nur reine 
Verschaltung, die keine Zeit frisst. Damit liefert eine automatisierte 
Übersetzung genau dort keine optimalen Ergebnisse, wo es am Nötigsten 
ist.

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #6458707:
> Lars R. schrieb:
>> myhdl ist hardwarenah. Der Tipp von Lothar ist gut. myhdl nimmt Dir
>> nicht die Denkarbeit ab.
>
> Es nimmt einem Tipparbeit ab, schränkt aber ein, denn eine ganze Reihe
> von Schaltungsstrukturen lassen sich da nicht gut beschreiben.

Beispiel?

von Markus (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Das Problem daran ist das übliche: das verwenden dann
> Softwareprogrammierer, denen das Konzept von echter Parallelität in

Damit wir uns nicht mißverstehen: Ich bin Chip-Entwickler. Mir sind die 
Stolperfallen bekannt. Ich will nur aus verschiedenen Gründen der 
Komplexität weg von Umsetzungen in Verilog (es geht um parallele 
Signalverarbeitung).

Soweit ich verstanden habe, sind myhdl und nmigen geeignet für 
explizites Hardware-Design, ich möchte keine Software HLS-Ansätze 
betreiben.

Um auf die ursprüngliche Thematik zurückzukommen, anders formuliert: Ich 
würde gerne prozedural DSV-Pipelines per Python generieren und die 
korrekte Funktion verifizieren können (und das für eine Vielzahl von 
konfigurierbaren Parametern). Der Prototyp läuft im FPGA. Soweit scheint 
das auch mit den Python-Ansätzen über Conversion nach Verilog zu gehen. 
Ich weiss nur noch nicht, ob ich auf nmigen oder myhdl setzen soll.

Weltbester FPGA-Pongo schrieb im Beitrag #6458707:
> Es nimmt einem Tipparbeit ab, schränkt aber ein, denn eine ganze Reihe
> von Schaltungsstrukturen lassen sich da nicht gut beschreiben.

Ich verstehe nicht ganz, was mir dein langer Text sagen soll. Was für 
Schaltungsstrukturen genau?

von Strubi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Moin,

ich versuchs mal knapp:

- myhdl ist schon als Framework zu sehen - es macht aus Python eine 
'echte' (im Prinzip selbstverifizierende) HDL, und laesst sich elegant 
mit spezifischen DSP-Datentypen erweitern. Leider ist die 'Coverage' 
nicht ganz komplett und es gibt unschoene Einschraenkungen resp. Bugs im 
'master' Tree.
- Ehemaliger Hauptentwickler hat kein Interesse an Weiterentwicklung -> 
unzaehlige proprietaere Forks
- nmigen: prozedurale Generierung von Hardware, keine klassische Analyse 
vorgesehen (Parsen des AST/Syntaxbaums)

Markus schrieb:
> Um auf die ursprüngliche Thematik zurückzukommen, anders formuliert: Ich
> würde gerne prozedural DSV-Pipelines per Python generieren und die
> korrekte Funktion verifizieren können (und das für eine Vielzahl von
> konfigurierbaren Parametern). Der Prototyp läuft im FPGA. Soweit scheint
> das auch mit den Python-Ansätzen über Conversion nach Verilog zu gehen.
> Ich weiss nur noch nicht, ob ich auf nmigen oder myhdl setzen soll.

Wenn du von Verilog her kommst, liest sich MyHDL besser und erscheint 
logisch. Aber: Pipelines kannst du nicht in dem Sinne mit der 
myhdl-Library generieren, nur handstricken oder eigene Frameworks 
draufsetzen. Faellt hier unter 'high level synthesis', dazu gibt es hier 
einige Threads.

Grundsaetzlich sehe ich (n)migen eher als ueblen Hack, aber es gibt eine 
Menge freier Cores, die darauf basieren. Auf der MyHDL-Seite gibt's kaum 
komplexe Beispiele, das liegt wohl an der Verschlossenheit der eher 
industriell gepraegten User.

Wenn du mit Limitierungen leben kannst: myhdl amortisiert sich trotz 
einiger Stolperfallen sehr schnell in der DSP-Domaene. Bei *migen ist 
die Wiederverwertbarkeit fragezeichenbehaftet.

Ansonsten zum Thema Weiterentwicklung (hierarchieerhaltende 
Ausgabe/Synthese per MyHDL):
Beitrag "MyHDL/Synthese per jupyosys"

Einige hardwarenahe Beispiele sind da im Browser per jupyter Notebook 
abspulbar (Simulation sowie Synthese).

Igendwann naechstes Jahr wird wohl noch eine modulare Ausgabe in VHDL 
dazukommen, modulo MyHDL-Maintainerpolitik.

von Christian M. (chipmuenk)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe versucht myhdl zu benutzen, um aus einer Python-Software heraus 
synthetisierbare Filterblöcke zu generieren, bin aber letzten Endes 
gescheitert. Ich habe zwar früher Chips in VHDL und ganz früher in 
Verilog entworfen aber ich bin mit Syntax und dem Ökosystem von myhdl 
nicht zurechtgekommen und habe nach 2 Jahren frustriert das Handtuch 
geworfen. Für mich hat es einfach nicht gepasst, mit der Community bin 
ich auch nicht warm geworden.

Mit migen habe ich relativ schnell erste Erfolge gehabt und versuche 
jetzt auf nMigen umzusteigen, ich komme mit dem Ansatz besser klar, aber 
momentan fehlt mir die Zeit. Mir gefällt jedenfalls der Ansatz, mit 
Python Fixpointblöcke komfortabel testen und analysieren (im Zeit- und 
Frequenzbereich!) und dann auch als HDL exportieren zu können. Als 
Proof-of-Concept habe ich FIR-Filter erzeugt mit optionaler Sättigung 
und Trunc/Round/Fix Quantisierung. Ich würde gerne als nächstes ein paar 
einfache IIR-Filter generieren, hoffentlich habe ich Anfang nächsten 
Jahres wieder mehr Zeit.

Ein Nachteil von (n)Migen ist übrigens der fehlende VHLD-Export (falls 
Du das brauchst).

Wenn Du Interesse hast, können wir uns ja mal kurzschließen.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
Christian M. schrieb:
> Ich habe versucht myhdl zu benutzen, um aus einer Python-Software heraus
> synthetisierbare Filterblöcke zu generieren,

Willkommen im Forum!

pyfda wurde hier schon ein paar mal weiterempfohlen. Danke dafür.

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.