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)


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)


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


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)


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)


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)


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)


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)


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)


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)


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)


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.

von Guy Eschemann (Gast)


Lesenswert?

Ich kenne nur MyHDL und der Hauptvorteil ist, daß man mit einer modernen 
Programmiersprache (Python) arbeiten kann. Das ermöglicht die Verwendung 
von entsprechenden Entwicklungstools und (noch wichtiger) Bibliotheken. 
Die Syntax ist etwas kompakter als VHDL, so daß man sich auch etwas 
Tipparbeit spart. Es gibt einen eingebauten Simulator, was gegenüber 
VHDL und Verilog auch ein großer Vorteil ist.

Das größte Problem was für mich immer, daß man keine VHDL/Verilog IPs 
mitsimulieren kann. Da fast jedes Design heutzutage solche IPs benutzt, 
ist das für die Entwicklung auf Top-Level Ebene für mich ein KO 
Kriterium; aber für die Entwicklung von reinen RTL-Subkomponenten 
durchaus zu gebrauchen. Ein weiterer Nachteil war, daß man keine 
parametrierbare Komponenten (mit Generics) generieren kann.

Hier ein Link zu meinem MyHDL-Vortrag auf dem FPGA Kongress 2014, falls 
du ihn noch nicht kennst: 
https://www.slideshare.net/GuyEschemann/2014-all-programmabe-days-fpga-design-with-python

Wenn es um die Entwicklung von DSP-Blöcken geht ist HLS (High-Level 
Synthese) meiner Meinung nach das Werkzeug der Wahl. Die Eingabesprache 
ist zwar kein Python, sondern C oder C++, aber diese Werkzeuge können 
sehr effizient und flexibel sequenziellen Code nach RTL (VHDL oder 
Verilog) kompilieren.

von Martin S. (strubi)


Lesenswert?

Guy Eschemann schrieb:
> Das größte Problem was für mich immer, daß man keine VHDL/Verilog IPs
> mitsimulieren kann

Es gibt ein CoSimulations-Objekt, was nach aussen wie ein HDL Block 
fungiert, und via Pipe mit einem V*-Simulator per VPI spricht. Das ist 
nicht wahnsinns schnell, aber reicht meist. VPI hat halt Limitierungen. 
Ansonsten gibts noch andere Moeglichkeiten per GHDL ueber das 
(abgespeckte) VHPI-Interface, da kann man mit shared Memory (schnell) 
oder ueber Netzwerk (verteilte co-Simulation) arbeiten.

Guy Eschemann schrieb:
> Wenn es um die Entwicklung von DSP-Blöcken geht ist HLS (High-Level
> Synthese) meiner Meinung nach das Werkzeug der Wahl. Die Eingabesprache
> ist zwar kein Python, sondern C oder C++, aber diese Werkzeuge können
> sehr effizient und flexibel sequenziellen Code nach RTL (VHDL oder
> Verilog) kompilieren.

HLS geht auch wunderbar per Python (IMHO viel maechtiger als per 
C++-Ansatz). Filterdesign mit genau den Bitbreiten, die man benoetigt 
(modulo Fehlerbits) gehen da natuerlich wie gehabt mit den klassischen 
Octave/Matlab-Designhilfen.
Seit yosys muss man auch den fehleranfaelligen Weg (Verifikation) ueber 
pre-synthesis-Konversion in V*-Sprachen nicht mehr gehen.
Ist aber nicht Teil von MyHDL und wird es wohl auch nicht mehr werden.

von Lars R. (lrs)


Lesenswert?

Martin S. schrieb:
> Seit yosys muss man auch den fehleranfaelligen Weg (Verifikation) ueber
> pre-synthesis-Konversion in V*-Sprachen nicht mehr gehen.
> Ist aber nicht Teil von MyHDL und wird es wohl auch nicht mehr werden.

Für mich (und vermutlich auch für andere) ist der Weg über V* kein 
Nachteil sondern ein Vorteil.

Spontan verstehe ich auch nicht, wo der Nachteil liegen soll. Wenn es 
funktioniert, dann brauchst das V* ja nicht angucken. Wenn irgend 
kleiner Fehler im Tool drin ist, dann suchst Du Dich kaputt, wenn es von 
Python direkt in die Netzliste geht.

von Martin S. (strubi)


Lesenswert?

Lars R. schrieb:
> Spontan verstehe ich auch nicht, wo der Nachteil liegen soll. Wenn es
> funktioniert, dann brauchst das V* ja nicht angucken.

Wenn du MAC (multiply-accumulate) z.B. mit sign-extension 
implementierst, stoesst du bei einer Latte von Umsetzungen via 
V*-transfer auf Bugs in der Synthesesoftware. iverilog rechnet's dann 
z.B. richtig, aber die FPGA-HW macht was anderes. Dasselbe auch auf der 
VHDL-Seite, da waere eigentlich alles sehr streng definiert (keine 
impliziten Konversionen wie bei Verilog), nutzt aber nix, wenn 
Hersteller den Standard verstuemmeln/ignorieren.
Dazu kommt leider, dass upstream-myhdl diesen Typ fehlerhafter Umsetzung 
bei der VHDL-Ausgabe seit Jahren ungefixt laesst.

Naechster Punkt ist, dass die Synthese aus dem funktionalen V*-Source 
'erraten' muss, was sie instanzieren soll. Einfacher ist es, ein 
Konstrukt direkt in eine Blackbox (Primitive) zu uebersetzen, welche 
bereits verifiziert ist.
Das ist zwar in diesem Zwischenschritt nicht portabel a la V*, aber gibt 
bereits auf der HLS-Ebene eine optimale Kontrolle darueber, was 
instanziert werden soll.
Der Source bleibt dabei derselbe, nur die 'design rules' aendern sich 
per FPGA-Architektur. Der Debugging-Overhead haelt sich dank 
divide-et-impera und den Moeglichkeiten zur laufenden Verifikation 
ziemlich in Grenzen. Meistens sieht man sofort in der 
post-syn-verifikation (Co-Simulation der funktionalen Beschreibung gegen 
synthetisierte Fassung) was schieflaeuft.

von Lars R. (lrs)


Lesenswert?

Martin S. schrieb:
> Lars R. schrieb:
>> Spontan verstehe ich auch nicht, wo der Nachteil liegen soll. Wenn es
>> funktioniert, dann brauchst das V* ja nicht angucken.
>
> Wenn du MAC (multiply-accumulate) z.B. mit sign-extension
> implementierst, stoesst du bei einer Latte von Umsetzungen via
> V*-transfer auf Bugs in der Synthesesoftware. iverilog rechnet's dann
> z.B. richtig, aber die FPGA-HW macht was anderes. Dasselbe auch auf der
> VHDL-Seite, da waere eigentlich alles sehr streng definiert (keine
> impliziten Konversionen wie bei Verilog), nutzt aber nix, wenn
> Hersteller den Standard verstuemmeln/ignorieren.

Für das nächste, im Moment noch unbekannte Problem:
Wie schnell gelange ich zu der Erkenntnis, ob der Fehler in 
Python-to-Netlist, im Simulator oder in den Hersteller-Libaries liegt?

Und wenn der Fehler beim Hersteller liegt, wie komme ich zu einem 
Workaround? Manuelles Nachoptimieren der V*-Verhaltensbeschreibung fällt 
bei Deinem Ansatz schon einmal weg.

Es gibt auch genug Sachen, die gehen in V* aber in Myhdl nicht; 
vielleicht auch nicht mit Deinem Ansatz. Bisher mit Myhdl kein Problem, 
das kann man im V*-Code anpassen. Falls aber nur noch Netzlisten-Code 
heraus kommst, wird es unschön; sowohl bzgl. Einbinden aus auch bzgl. 
Simulation.

> Naechster Punkt ist, dass die Synthese aus dem funktionalen V*-Source
> 'erraten' muss, was sie instanzieren soll.

Dafür ist sie da.

> Der Source bleibt dabei derselbe, nur die 'design rules' aendern sich
> per FPGA-Architektur. Der Debugging-Overhead haelt sich dank
> divide-et-impera und den Moeglichkeiten zur laufenden Verifikation
> ziemlich in Grenzen.

Es gibt auch noch Fehler in der physikalischen Hardware. Mit der 
kompletten Netzliste allein ist es mitunter schwierig mit dem Support.

Weiterhin: In der aktuellen Situation sind opensource-Synthese-tools bei 
den Herstellern noch nicht so etabliert/akzeptiert, wie bei der Software 
der gcc.
Was ist mit Hardwarefehlern, die versehentlich mit dem 
Herstellersynthese-Tool nicht zum Fehler im Design führen aber mit 
Python-to-Netlist schon?
Was ist mit undokumentierten Hardwarefehlern, die das 
Herstellersynthese-Tool absichtlich umschifft?

Bei gcc hat man erkannt, dass es mit llvm mitunter besser geht. Warum 
sollten wir bei der HW die Uhr wieder zurück drehen?

Wenn die V*-Verhaltensbeschreibung als Input für das Herstellertool 
nicht das Soll-Ergebnis liefert, dann kann gehe ich damit zum Hersteller 
oder ins Support-Forum. Mit einer Netzliste von extern geht das im 
Moment nicht oder nicht so gut.

Die Frage ist natürlich, was man möchte. Möchte man sich selbst ein 
All-in-One-Übersetzer-Tool bauen oder möchte man FPGA-Designs bauen. Bei 
mir ist es letzteres. Nicht zuletzt im eigenen Interesse helfe ich gern 
beim pin-down des Problems, jedoch benötige ich für jedes Problem einen 
Lösungsansatz, der in endlicher Zeit zum Ziel führt. Letztlich ist alles 
schon da gewesen (fehlerhaft Lib, Sim, Synthesetool, Hardware)



> Meistens sieht man sofort in der
> post-syn-verifikation (Co-Simulation der funktionalen Beschreibung gegen
> synthetisierte Fassung) was schieflaeuft.

Wenn das bei Dir effizient funktioniert, Hut ab. Ich kann zwar sofort 
sehen, dass etwas schief läuft, aber ich sehe nicht sofort, was bei 
einer Netlist schief läuft. Für Übersetzungen von Highlevel* zu 
Verhaltensbeschreibung-V*-Code kann ich das jedoch sehr wohl noch 
effizient (zB. Myhdl und Matlab).


Last but not least: Vertrauen in die Zuverlässigkeit. Myhdl und andere 
Python-basierte Ansätze werden bereits wenig genutzt. Der von Dir 
vorangetriebene Ansatz noch weniger. Das ist ein großes Minus beim 
Vertrauen in ein scheinbar funktionierendes, damit erzeugtes Design. Es 
hat Gründe, warum nicht plötzlich überall der chinesische FPGA mit 
zugehörigem Synthese-Tool benutzt wird. Ein wesentlicher davon ist die 
größe der bekannten Nutzerbasis.

Für die opensource-Synthese-Ansätze (yosys) hoffe ich das Beste. Die 
Nutzerbasis könnte da groß genug werden. Weniger optimistisch bin ich 
bzgl.  Tools, wo eins von Python zu Netzliste übersetzt, das nächste von 
Perl und das nächste von Java, usw. Die Nutzerbasis ist ja schon bei 
Python-zu-V*-Verhaltensbeschreibung relativ klein.
Ich vermute nicht, dass eine "Anflanschung" an yosys oder ähnlich zum 
erhofften Ziel führt.
Im Moment kann der Anwender jederzeit in die V*-Verhaltensbeschreibung 
schauen und jederzeit auf das Fallback "Herstellertool" gehen. Das hat 
man dann alles nicht mehr. Bei einem Problem steht man dann da und hat 
als Ansprechpartner praktisch nur Dich (und ggf. eine Handvoll weitere 
Personen, falls es mal dazu kommt).

Bei der Simulation besteht die Problematik mit dem Vertrauen ebenfalls. 
Das besteht im Moment bei Myhdl auch, aber da hat man ja auch noch die 
V*-Verhaltensbeschreibung. Bei Deinem Ansatz dann nur noch die 
Netzliste.

Dann Verifikationstools bzgl. des Desings (also der vom Nutzer 
geschriebene Code), dh. asserts, code coverage bis zu formale 
Verifikation. Und seien es auch nur die (neuesten) Opensource-Tools 
dafür. Das ist nicht möglich mit Deinem Ansatz, soweit ich es überblicke 
(oder baust Du das auch noch, quasi  allein). Mit Myhdl geht da noch 
was. Dort gibt es zwar Einschränkungen, die jedoch aus einem Konzept 
heraus entstehen, das an anderen Stellen wiederum wesentliche Vorteile 
hat.


Es doch nicht so, dass die Welt immer noch Verilog und VHDL benutzt, nur 
weil noch nie jemand eine bessere Idee hatte. Wir sind konservativer als 
die Embedded-Softwerker mit C, und das nicht ohne 
technisch-mathematischen Grund.

Natürlich gibt es die Highlevel-Ansätze für alles und jeden, sowohl bei 
SW, als auch bei HW. Aber das ist dann nicht das Replacement für MyHdl. 
Bisher war mein Verständnis, dass Dein Ansatz auch nicht in Richtung HLS 
geht.

von Martin S. (strubi)


Lesenswert?

@Lars: Ich weiss nicht genau, worauf du hinauswillst. Mein Eindruck ist, 
du verrennst dich da etwas. Ich halt's mal kuerzer:

Generell gilt: Irgend einem Tool als 'working reference' musst du 
vertrauen.
Darauf aufbauend ergibt sich die "Zuverlaessigkeit" der 
Verifikationskette.
Ob sich das fuer dich jeweils amortisiert, musst du selber evaluieren, 
hier gelten OpenSource-Prinzipien (kein Support, read the source).

Die Community, die Python-Ansaetze verfolgt, mag klein sein, wie du 
suggerierst. Spielt aber nicht wahnsinns Rolle, der V*-Mainstream 
interessiert marginal, es geht mir insbesondere um nachhaltige, gut 
wartbare IP-Cores, nicht, Tools zu 'verkaufen' (siehe OpenSource).

V* kann man nach wie vor ausgeben und einbinden (betr. Thema Workarounds 
zu Tools/HW-Bugs, falls noetig). Ich weiss nun nicht, von welchem Ansatz 
du redest, mit dem das dann nicht mehr gehen sollte. Die erwaehnte 
'Netzliste' ist im yosys-Fall die interne RTL-Representation (RTLIL). 
Die kannst du auch modular in Verilog ausgeben und durch die 
Verifikation spulen.

Was die erwaehnte HLS-Schiene insbesondere angeht: in-house-Tool, nicht 
Teil von MyHDL, setzt nur partiell darauf auf, Pipelines lassen sich 
auch in MyHDL-@blocks ausgeben.
Der Rest der Verifikationskette bleibt gleich.

Das Einkreisen der Fehler ist per Co-Simulation/Verifikation wenig 
dramatisch. Gibt's ein paar Beispiele zu im jupyosys-Hackerspace.

Grundsaetzlich unterscheidet sich obiger Ansatz nur von 'upstream', dass 
die Hierarchie beibehalten wird, und eine Blackbox-API dazukommt. Der 
Rest ist Interfacing zur entsprechenden RTL-Ausgabe (yosys).
Damit hat man mehr Kontrolle ueber die 'Inference' (Umsetzung einer 
funktionalen Beschreibung). Synthetisierbaren Code schreiben lernen wie 
in der V*-Welt muss man aber nach wie vor.

von Lars R. (lrs)


Lesenswert?

Martin S. schrieb:
> @Lars: Ich weiss nicht genau, worauf du hinauswillst.

Wie ich bereits geschrieben hatte: Die V*_Verhaltens_Beschreibung wird 
von vielen Anwendern benötigt. Dafür hatte ich diverse Gründe angegeben.

Martin S. schrieb:
> Die Community, die Python-Ansaetze verfolgt, mag klein sein, wie du
> suggerierst. Spielt aber nicht wahnsinns Rolle, der V*-Mainstream
> interessiert marginal, es geht mir insbesondere um nachhaltige, gut
> wartbare IP-Cores, nicht, Tools zu 'verkaufen' (siehe OpenSource).

In vielen anderen Fällen muss Code gereviewt werden und ggf. auch 
verifiziert werden. Mit Verifikation meinte ich nicht das Tool sondern 
die Verhaltensbeschreibung. Verifikations-Tools, die auf MyHDL laufen, 
sind mir nicht bekannt. Auch Opensource-Tools laufen nur auf V*.

Martin S. schrieb:
> Generell gilt: Irgend einem Tool als 'working reference' musst du
> vertrauen.
> [...]
> Ob sich das fuer dich jeweils amortisiert, musst du selber evaluieren,
> hier gelten OpenSource-Prinzipien (kein Support, read the source).

Richtig. Dabei geht es nicht so sehr darum, ob es opensource ist und ob 
es etwas kostet oder nicht.

Ein Tool, das die Netzliste erzeugt, erfordert viel mehr Vertrauen als 
ein Tool, das nur eine Verhaltensbeschreibung erzeugt.

Die Fragen sind:
. Wer hat es entwickelt? Wie viele Personen? Welche Firma? Opensource 
ist ok, aber eine Einmann-show mit 0-5 Anwendern und auch noch direkt 
auf die Netzliste ist schwierig. (Das ist auch der Grund, warum es mit 
myHDL ein Stück weit funktioniert hat. Die Schritte, die myHDL macht, 
sind händisch nachvollziehbar. Fehler sind schnell gefunden und 
eingegrenzt)
. Wie viele Personen benutzen es und haben es bereits benutzt?
. Wer könnte (ggf. gegen Bezahlung) Support bieten?
. Beeinflusst die Benutzung des Tools das Fehlerfinden oder den Support 
in nachfolgenden Schritten und falls ja wie stark? Von ganz einfachen 
Dingen wie dem Benutzen der Xilinx ILA bis hin zum Finden von 
Hardwarefehlern im FPGA-Silicon oder auf dem PCB.

Das sieht meiner Ansicht nach eben nicht ganz gut aus, wenn man Stand 
heute prinzipiell von Python direkt auf die Netzliste geht, bzw. gehen 
muss. Es sieht eher so aus, dass es bzgl. der angesprochenen Themen das 
Leben erschwert.

Die Daseinsberechtigung von Deinem Ansatz will ich keinesfalls in Frage 
stellen. Grund meiner Argumentation ist, dass ich (noch) nicht 
nachvollziehen kann, warum es jemand anders als Du selbst benutzen 
sollte.

Dein Ansatz mag Fehler nicht haben, die myhdl hat, und er mag mehr 
Features haben, die myhdl hat. Aber das nützt nur bedingt, wenn es mich 
dafür an anderer Stelle ein Vielfaches der Zeit kostet oder kosten kann.

: Bearbeitet durch User
von Martin S. (strubi)


Lesenswert?

Lars R. schrieb:
> Ein Tool, das die Netzliste erzeugt, erfordert viel mehr Vertrauen als
> ein Tool, das nur eine Verhaltensbeschreibung erzeugt.

Dazu musst du in diesem Fall yosys vertrauen. Nochmal: Python erzeugt 
die noch abstrakte RTLIL 'intermediate representation', keine Netzliste. 
Ansonsten musst du das oben aufgelistete einfach selbst verifizieren. An 
einer Stelle in der V*-Kette musst du bei manchen Marken auch einer 
closed-Source-Synthese vertrauen. Ich habe hier fuer VHDL ca. 20 
Testcases, wo bei Lattice/Xilinx die unterschiedlichsten Sachen bei 
rauskommen...

Lars R. schrieb:
> Die Fragen sind:
> ...

Solche 'Marktforschungs'-Fragen zu beantworten habe ich mir eigentlich 
abgewoehnt.
Ich kann dazu allerdings sagen:

- Nutze github
- Die meisten Forks von MyHDL sind Einmann-Shows, wie GHDL
- Die Wahrscheinlichkeit, dass Firmen aufgekauft werden, ist hoeher, als 
dass Einmann-OpenSource von github getilgt wird
- Wenn konkret ein Bug auftaucht, wird er typischerweise gefixt

Was die Fehlersuche in Bezug auf HW angeht: Da wird es sehr 
FPGA-spezifisch. Ich habe bisher nur ECP5 in der aktiven Anwendung unter 
yosys und kann auch nur da Support bieten.

Lars R. schrieb:
> Aber das nützt nur bedingt, wenn es mich
> dafür an anderer Stelle ein Vielfaches der Zeit kostet oder kosten kann.

Genau deswegen muss sich ein OpenSource-Tool/dessen Erweiterung auch 
fuer mich im Projekt amortisieren. Sonst haette ich damit gar nicht erst 
angefangen. Duerfte so ziemlich offensichtlich sein :-)

Wie sich die Bilanz im Einzelnen auswirkt, muss jeder fuer sein Projekt 
selber rausfinden. Was geht und was nicht geht, ist IMHO erst mal 
ausreichend dokumentiert.

Lars R. schrieb:
> Dein Ansatz mag Fehler nicht haben, die myhdl hat, und er mag mehr
> Features haben, die myhdl hat

Lies doch nochmal oben durch, was ich geschrieben habe. Auch zwischen 
HLS und RTLIL liegt die gleiche myhdl-kompatible Struktur.
Du kannst also nach wie vor V* nach Lust und Laune ausgeben und mit was 
auch immer verifizieren, oder gegen die RTLIL-Variante gegenchecken. 
*migen dito.

Allerdings: das grundsaetzliche bereits oefters angesprochene Problem 
bei MyHDL ist halt, dass viele Python'sche Konstrukte nicht 
synthetisierbar sind und es da bereits Diskrepanzen zwischen den 
verschiedenen Backends gibt. Mit der Baustelle wird man eine Weile leben 
muessen. Und da geht definitiv am meisten Zeit bei drauf. Bei *migen ist 
das (noch) simpler.

Python kann grundsaetzlich Selbst-Verifikation per AST-Analyse (wie es 
MyHDL macht), somit kann man per Spezifikation von Designregeln schon 
fruehzeitig meckern: Synthetisiert so nicht fuer Target/Tool X/Y.

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]
  • [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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.