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?
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.
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.
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.
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.
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.
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?
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?
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):
https://www.mikrocontroller.net/topic/496432
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.
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.
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.
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.
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.
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.
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.
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.
@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.
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.
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.
