Moin,
im Rahmen einiger komplexer DSP-Projekte sind hier als ehemals 'in-house
hack' einige Tools entstanden, die im letzten Pandemiejahr so
umgestrickt wurden, damit sich MyHDL-Designs leichter portieren resp.
wiederverwerten lassen.
Falls jemand aus der akademischen Ecke Lust hat, sich an einem neuen
Ansatz (aber einem soweit gut etablierten Python-HDL-Dialekt)
auszutoben:
https://github.com/hackfin/myhdl.v2we
Grobe Zusammenfassung was drin ist:
- Docker-Container, basierend auf Jupyter NB Umgebung, laeuft 'online'
im Binder (oder zuhause im Docker-Environment)
- Momentan hierarchische Ausgabe nur als VHDL
- Tests/Verifikation per GHDL-Opensource-Simulator
- Beispiele zum 'Aufpeppen' von MyHDL mit Hardware-Generatoren (Einfache
Prozedural-Instanzierung bis Vektoren-Pipelines)
Aber Achtung: Nur was fuer Python-Enthusiasten (bevor das Geunke aus der
konservativen HDL-Ecke losgeht). Nicht fuer den produktiven Einsatz!
Martin S. schrieb:> Nicht fuer den produktiven Einsatz!
also nur zum Spielen, oder was ? Wird die Verwendung von Python nicht
genau deshalb gepriesen, weil es die Produktivität erhöht?
Oder was habe ich hier falsch verstanden?
Ich meine, nicht, dass ich das propagieren möchte, siehe meinen
Kommentar:
Beitrag "Re: Frequenzzähler"
Weltbester FPGA-Pongo schrieb im Beitrag #6761577:
> also nur zum Spielen, oder was ? Wird die Verwendung von Python nicht> genau deshalb gepriesen, weil es die Produktivität erhöht?
Schon, aber der Neuaufwasch ist noch lange nicht so weit verifiziert bzw
eingefroren, dass man die grossen Projekte damit schaukeln sollte.
Daher: Obligater Disclaimer.
Tobias B. schrieb:> Verstehe ich das richtig: MyHDL das pendant zu z.B. Vivado HLS nur eben> mit Python statt C als Modellierungssprache?
MyHDL ist ansich zur V* HDL aequivalent, mit einer gesunden Arithmetik
(modulo jahrealte Bugs..) und ein paar mehr Moeglichkeiten. Laesst sich
nur, wie es ist, schlecht auf HLS aufbohren. Deswegen steckt hier im
Innern ein 'Kernel' mit anderer Architektur, was MyHDL bis zu einem
gewissen Punkt emuliert.
HLS macht man dann eher mit seinen eigenen Erweiterungen. Da sind die
Geschmaecker sehr verschieden, nach diversen ueblen Hacks wie man es von
der C-HLS mit einfach hinschreiben gewohnt ist, bin ich eher bei den
Generatoren-Konzepten von Python haengengeblieben. Zum Ansatz, siehe
Beispiel im Container (RGB->YUV-Pipeline).
Martin S. schrieb:> MyHDL ist ansich zur V* HDL aequivalent, mit einer gesunden Arithmetik> (modulo jahrealte Bugs..) und ein paar mehr Moeglichkeiten. Laesst sich> nur, wie es ist, schlecht auf HLS aufbohren. Deswegen steckt hier im> Innern ein 'Kernel' mit anderer Architektur, was MyHDL bis zu einem> gewissen Punkt emuliert.
Ahhhh alles klar!
Martin S. schrieb:> Zum Ansatz, siehe> Beispiel im Container (RGB->YUV-Pipeline).
Ok, da gugg ich mal rein. Vielen Dank fuer die Infos! :-)
Tobias B. schrieb:> Verstehe ich das richtig: MyHDL das pendant zu z.B. Vivado HLS> nur eben mit Python statt C als Modellierungssprache?
Nein, MyHDL ist ähnlich wie VHDL/Verilog. Aber in der Python-Umgebung
hat man die ganzen Bibliotheken für z.B. Testsuites zur Verfügung.
hi,
habe etwas mit Jupyter experimentiert und finde den Ansatz
grundsätzlich interessant um Ergebnisse nachzuvollziehen.
Allerdings habe ich noch Mühe mit dem Schlagwort HLS. Wo kommt diese
genau zum Einsatz und wie verbessere ich damit meinen Workflow mit
VIVADO usw.?
Zudem stellt sich die Frage nach der Verifikation, also daß die
Hardwareumsetzung auch das Richtige liefert. Da sehe ich bisher keine
Vorteile gegenüber VHDL. Also wie habe ich eine Garantie, daß mein
Modell in Python richtig synthetisiert und ich nicht in der VHDL die
Fehler suchen muß.
Markus W schrieb:> Also wie habe ich eine Garantie, daß mein> Modell in Python richtig synthetisiert und ich nicht in der VHDL die> Fehler suchen muß.
Woher hast du die Garantie, dass ein Synthese Tool den VHDL Code richtig
synthetisiert? Oder das ein C-Compiler den gewuenschten Maschinencode
produziert? ;-)
Im Prinzip musst du wie bei allem eine Analyse und Risikobewertung
deiner Entwicklungswerkzeuge durchfuehren und dann entscheiden ob die
fuer deine Anwendung geeignet sind oder nicht. In der Medizintechnik
wird das z.B. in der IEC 62304 gefordert, andere Bereiche haben da
andere Normen mit aehnlichen Anforderungen.
Tobias B. schrieb:> Woher hast du die Garantie, dass ein Synthese Tool den VHDL Code richtig> synthetisiert? Oder das ein C-Compiler den gewuenschten Maschinencode> produziert? ;-)>> Im Prinzip musst du wie bei allem eine Analyse und Risikobewertung> deiner Entwicklungswerkzeuge durchfuehren und dann entscheiden ob die> fuer deine Anwendung geeignet sind oder nicht. In der Medizintechnik> wird das z.B. in der IEC 62304 gefordert, andere Bereiche haben da> andere Normen mit aehnlichen Anforderungen.
Deshalb ist es auch so wichtig, dass ein derartiges Tool zu VHDL
übersetzt und nicht nur direkt in eine Netzliste oder gar bitstream.
Auch Matlab HDL Coder und Co übersetzen zu VHDL und nicht gleich direkt
in eine Netzliste.
Markus W schrieb:> Allerdings habe ich noch Mühe mit dem Schlagwort HLS.> Wo kommt diese genau zum Einsatz und wie verbessere ich> damit meinen Workflow mit VIVADO usw.?
HLS ist dort sinnvoll, wo man mit geringen HDL-Kenntnissen einen
bestimmten Algorithmus implementieren muss und dafür auch einen gewissen
Overhead in Kauf nehmen kann. Effektiv genauso die gleiche Diskussion
wie bei Software zum Thema "Hochsprache gegen Assembler".
MyHDL fällt genau da allerdings nicht drunter, weil es keine HLS macht.
Du beschreibst deine Hardware genauso wie in VHDL oder Verilog.
> Zudem stellt sich die Frage nach der Verifikation, also daß die> Hardwareumsetzung auch das Richtige liefert. Da sehe ich bisher> keine Vorteile gegenüber VHDL.
Wenn es dir um HLS im Allgemeinen geht, dann schaust du in die falsche
Richtung, denn die eigentlichen Vorteile liegen woanders: Weniger
Aufwand für hinreichendes Ergebnis, also weniger Code und schnellere
Implementierbarkeit. Der Verifikationsaufwand bleibt gleich.
> Also wie habe ich eine Garantie, daß mein Modell in Python richtig> synthetisiert und ich nicht in der VHDL die Fehler suchen muß.
Garantiert dir Xilinx, dass Vivado dein VHDL oder Verilog fehlerfrei
synthetisiert? Meines Wissens eindeutig nicht. Für HLS gilt das noch
viel mehr.
Du musst dich auf dein Tooling verlassen können, das gilt aber
grundsätzlich, und Garantien gibt es keine. Bei MyHDL kannst du in die
Sourcen gucken und es fällt hinten eine gewöhnliche HDL raus, die du
klassisch verifizieren kannst. Bei Xilinx kannst du nicht in die Sourcen
schauen.
S. R. schrieb:> Du musst dich auf dein Tooling verlassen können, das gilt aber> grundsätzlich, und Garantien gibt es keine. Bei MyHDL kannst du in die> Sourcen gucken und es fällt hinten eine gewöhnliche HDL raus, die du> klassisch verifizieren kannst. Bei Xilinx kannst du nicht in die Sourcen> schauen.
Bei MyHDL kommt eine Verhaltensbeschreibung in VHDL mit Prozessen oder
Verilog heraus.
Im Gegensatz dazu kommt beim Tool des TO, soweit ich das Verstanden
habe, jedoch keine VHDL Verhaltensbeschreibung heraus sondern eine VHDL
RTL-Netzliste. Das erschwert die Verifikation massiv gegenüber"MyHDL ->
VHDL Verhaltensbeschreibung".
Vivado Synthese und vergleichbare Tools nutzen viele Anwender.
Ok, ich sehe schon, ich muß mich da tiefer in die Materie einarbeiten.
Habe soweit verstanden, daß das Problem nach der VHDL nicht gelöst ist.
Das ist mein Problem, bei Altera muß ich die Prozesse teils anders
entwerfen als mit VIVADO. Da hat MYHDL etwas Arbeit erspart.
Ein paar der Beispiele habe ich laufen lassen, und habe gut lesbare VHDL
herausbekommen. @Lars, was verstehst du unter VHDL Netzliste, und wieso
erschwert das Verifikation?
Markus W schrieb:> Ok, ich sehe schon, ich muß mich da tiefer in die Materie einarbeiten.> Habe soweit verstanden, daß das Problem nach der VHDL nicht gelöst ist.
Es gibt sehr wohl Opensource-Tools, die bis zum Bitstream-File umsetzen.
Die Entwicklung diesbezüglich kommt auch relativ schnell und erfolgreich
voran.
> Das ist mein Problem, bei Altera muß ich die Prozesse teils anders> entwerfen als mit VIVADO.
Inwiefern?
> Da hat MYHDL etwas Arbeit erspart.> Ein paar der Beispiele habe ich laufen lassen, und habe gut lesbare VHDL> herausbekommen. @Lars, was verstehst du unter VHDL Netzliste, und wieso> erschwert das Verifikation?
Damit meine ich eine RTL-Beschreibung.
Wenn jedoch, wie bei MyHDL mit einigen Einschränkungen der Fall, eine
lesbare VHDL Verhaltensbeschreibung heraus kommt, dann muss ich das
MyHDL-Tool gar nicht erst verifizieren.
Lars R. schrieb:> Inwiefern ?
Aus irgendeinem Grund (vergessen) haben wir an der TH gelernt, den
asynchronen Reset in der Prozeßschreibweise zu benutzen (für Altera
Cyclone). Der Code machte dann beim Umzug auf VIVADO Ärger und mußte auf
synchronen Reset umgeschrieben werden. Fand die Umschaltung mit MYHDL
recht elegant, aber es kamen eine Menge neuer Probleme dazu, wie, daß
bestehende Module nicht einfach eingebunden werden konnten, falsche
Ergebnisse, usw.
Naja ich mache da mal weiter.
Moin,
Lars R. schrieb:> Im Gegensatz dazu kommt beim Tool des TO, soweit ich das Verstanden> habe, jedoch keine VHDL Verhaltensbeschreibung heraus sondern eine VHDL> RTL-Netzliste. Das erschwert die Verifikation massiv gegenüber"MyHDL ->> VHDL Verhaltensbeschreibung".
Das ist grundsaetzlich nicht richtig.
Wie oben steht, wird hier erst mal nur VHDL ausgegeben. Allerdings
modular, nicht 'geflacht' wie in myHDL. Somit lassen sich auch externe
HDL-Module per @blackbox einbinden.
Die Art und Tiefe der Verifikation ist eine Sache der Target-Ausgabe (da
gehen per Yosys-Backend auch Netzlisten). Diese lassen sich sehr wohl
bis auf Gate-Level verifizieren. Der Gag an den Generatoren ist zudem,
dass sich bei einigen neuartigen FPGA-Architekturen die Verifikation
recht einfach handhaben laesst und sich Induktionsschritte (wenn es fuer
N korrekt ist, ist es auch fuer N+1 korrekt) gleich in die Design-Regeln
fuer das Target einbauen lassen.
Wie svenska schreibt, muss man nach der VHDL-Ausgabe (und der
Ueberpruefung der funktionalen Korrektheit) wiederum dem Synthesetool
vertrauen. Gerade bei Memory-Modellierung erlebt man da bekanntlich bei
X, L, I/A immer wieder Ueberraschungen. Auf der myHDL->V*HDL Ebene ist
das immer noch das bisherige trial&error.
Betr. HLS: Muesste man ev. erst ausholen:
- klassisch myHDL parst die Sourcebeschreibung (den AST), und uebersetzt
in eine Ziel-HDL. Designregeln per Target gibt es nicht.
- v2we uebersetzt in eine Zwischensprache ('IRL') und fuehrt sie
effektiv
aus, um das Zielformat (HDL oder Netzliste) zu erzeugen.
Mit zweiterem Ansatz hat man viel mehr Moeglichkeiten. Deswegen kann ich
mir z.B. eine Signalklasse definieren, die gezielt fuer ein Target
(Netzliste/FPGA) inferiert (d.h. in Primitiven umsetzt). Dieselbe
Beschreibung, z.b. eine Matrizenmultiplikation, kann ich also in
Designregel A fuer Target F ausgeben (z.b. fixpoint 24 bit), oder per
LLVM fuer eine CPU transpilieren. Und, wenn noetig, im Hintergrund die
Verifikation ueber die erzeugten Primitiven ablaufen lassen. Dann muss
ich nur noch dem Gate-Level-Modell der Primitiven vertrauen.
Schlussendlich kann man mit diesen Signalklassen dann schreiben:
1
@hls.designrule_A
2
def func(M, N, O):
3
result = M * N + O
4
return result
und muss das noetige Aufrollen in eine Pipeline mit der entsprechenden
Designregel verarzten. Ueber die Art der Pipeline bestimmt der
HDL-Designer dann allerdings nicht mehr im obigen Code und da steckt
dann grundsaetzlich die Crux in der HLS a la Vivado. Kann bis zu einem
gewissen Punkt tun, dann wird's undurchsichtig.
Was die Fehlersuche und schlussendlich Verifikation angeht, sollte man
dem HLS-Hype in der Tat eher argwoehnisch begegnen. Deswegen bin ich
auch beim Dogma "Selbermachen zaehlt" gelandet. Wenn die Zielarchitektur
gut bekannt ist, baut man sich seine Pipeline lieber erst mal manuell
(siehe auch 'Pipeline Generators' in einem der Notebooks). Ist ein
Element dann verifiziert, packt man's in eine Klasse oder HW-Modul (je
nach eigenem Geschmack).
Darum nochmal: Das v2we-Kernel ist auf HLS ausgelegt worden, aber seine
persoenliche HLS muss sich der Anwender selber stricken. Das Kernel ist
grundsaetzlich agnostisch betr. HLS und erweiterter Datentypen und
handhabt primaer die Zwischendarstellung IRL.
Markus W schrieb:> falsche> Ergebnisse, usw.
Lass mich raten: Vorzeichenbehaftete Erweiterungen (Signed extensions)?
Das ist bei myHDL ein Trauerspiel, der Bug (nur VHDL-Ausgabe) wird von
den Maintainern geflissentlich (seit rund 10 Jahren) ignoriert.
Martin S. schrieb:> Moin,>> Lars R. schrieb:>> Im Gegensatz dazu kommt beim Tool des TO, soweit ich das Verstanden>> habe, jedoch keine VHDL Verhaltensbeschreibung heraus sondern eine VHDL>> RTL-Netzliste. Das erschwert die Verifikation massiv gegenüber"MyHDL ->>> VHDL Verhaltensbeschreibung".>
Hallo Martin,
die Diskussion hatten wir bereits im letzten Thread.
MyHDL setzt nahezu Zeile für Zeile die MyHDL-Datei in eine
VHDL-Verhaltensbeschreibung um. Deshalb muss man keine Analyse von MyHDL
machen, man kann den erzeugten VHDL-Code als Ausgangslage betrachten,
aber nicht mit komplett flacher Hierarchie. Gut wäre es deshalb gewesen,
wenn sich bei MyHDL noch etwas bzgl. Lesbarkeit des erzeugten Codes
(Hierarchie wie bei Dir, VHDL-2008-Output) getan hätte...
Deine Weiterentwicklung setzt in eine RTL-Beschreibung um.
Deine Weiterentwicklung/Ansatz mag Vorteile haben, viel praktischer sein
und bereits langjährig bestehende Bugs endlich beheben/aus dem Weg
räumen. Aber das sind nicht die entscheidenden Kriterien. Das Tool
benutzt kaum jemand. Damit erreiche ich niemals ein Confidence-Level wie
mit anderen, millionenfach benutzten Tools.
Die für eine "Community" erforderliche, kritische Menge fehlt
(inzwischen?) bereits bei MyHDL, von Deinem Ansatz/Wrapper/Übersetzer
ganz zu schweigen.
MyHDL wird immer weniger benutzt werden. Inzwischen sind Entwicklung und
Communities bei Verilator, GHDL, OSVVM und Python-basierte Testansätze
voran gekommen. VHDL-2008 ist inzwischen verbreitet und mit VHDL-2019
wird die VHDL-Syntax weiter verbessert.
Neben all dem und zusätzlich den kommerziellen Tools (von Matlab HDL
Coder bis Speedgoat) braucht es keinen weiteren MyHDL-Dialekt/Tool.
Vielleicht hätte ein fork von MyHDL eine Chance gehabt. Die
MyHDL-Simulation mit bitgenauer Arithmetik ist/war praktisch.
Lars R. schrieb:> Deine Weiterentwicklung setzt in eine RTL-Beschreibung um.
Nein. Du verstehst das falsch. Gerne kannst du dir die obigen Beispiele
im Binder ansehen und nachvollziehen, dass mit dem Default-VHDL-target
modulare, hierarchisch tracebare VHDL ausgegeben wird und keine
RTL-Netzliste.
Lars R. schrieb:> Die für eine "Community" erforderliche, kritische Menge fehlt> (inzwischen?) bereits bei MyHDL, von Deinem Ansatz/Wrapper/Übersetzer> ganz zu schweigen.
Die Community interessiert mich gelinde gesagt wenig bis gar nicht, mit
der Ausnahme: Wenn was sinnvolles zurueckkommt und keinen Supportaufwand
kostet.
Auch hier wieder: Mich interessiert am Ende des Tages ein gut wartbarer
Core fuer dessen korrekte Funktion ich haften kann, was die andern mit
den Tools machen, ist meist nur bei einigen wenigen akademischen
Anwendungen oder neuartigen Architekturen spannend.
Und: 'Confidence Level' am Hype/Google-Statistiken festzuknuepfen ist
ein ziemlicher Holzweg :-) Kann man sehr gut bei div. Hacks wie (n)migen
sehen.
Was nicht heissen soll, dass das Ding bugfrei ist, da, wie gesagt,
Neuaufwasch. Da kann sich einiges einschleichen, und einige Portierungen
sind noch nicht verifiziert/abgeschlossen, s.o.
Lars R. schrieb:> Vielleicht hätte ein fork von MyHDL eine Chance gehabt. Die> MyHDL-Simulation mit bitgenauer Arithmetik ist/war praktisch.
Nein. Diesen Fork gab/gibt es bereits, bzw. gibt es unzaehlige Forks,
die schon vom SW-Aspekt her nicht mehr wartbar sind.
In den myHDL-Tree werde/wuerde ich nicht weiter investieren, das ist
IMHO aus architektonischen und politischen Gruenden ein totes Pferd.
Mein Fokus liegt genaugenommen auf der IRL und den Moeglichkeiten mit
yosys, myHDL-kompatibilitaet (beschraenkt) ist erst mal Prototyp im
Sinne von 'works for me'.
Lars R. schrieb:> Neben all dem und zusätzlich den kommerziellen Tools (von Matlab HDL> Coder bis Speedgoat) braucht es keinen weiteren MyHDL-Dialekt/Tool.
Schau, solche Aussagen hoere ich des oefteren aus der Trollecke. Wenn
ich feststelle, dass nichts konstruktives zurueckkommt, klinke ich mich
aus der Diskussion aus.
'Legacy' myHDL hat, abgesehen von Maintenance-Problemen relevante
strukturelle Defizite, die komplexe IP-Core-Entwicklungen behindern.
Deswegen braucht es Weiterentwicklung. Hat sich auch schon ganz konkret
amortisiert.
Martin S. schrieb:> Lars R. schrieb:>> Deine Weiterentwicklung setzt in eine RTL-Beschreibung um.>> Nein. Du verstehst das falsch. Gerne kannst du dir die obigen Beispiele> im Binder ansehen und nachvollziehen, dass mit dem Default-VHDL-target> modulare, hierarchisch tracebare VHDL ausgegeben wird und keine> RTL-Netzliste.
Unter https://github.com/hackfin/myhdl.v2we/tree/master/examples habe
ich keine VHDL-Verhaltensbeschreibungen gesehen. Hast Du bitte ein
konkretes Beispiel für mich?
> Lars R. schrieb:>> Die für eine "Community" erforderliche, kritische Menge fehlt>> (inzwischen?) bereits bei MyHDL, von Deinem Ansatz/Wrapper/Übersetzer>> ganz zu schweigen.>> Die Community interessiert mich gelinde gesagt wenig bis gar nicht, mit> der Ausnahme: Wenn was sinnvolles zurueckkommt und keinen Supportaufwand> kostet.> Auch hier wieder: Mich interessiert am Ende des Tages ein gut wartbarer> Core fuer dessen korrekte Funktion ich haften kann
Klar. Und mich interessiert, wofür ich haften kann. Bei einem Tool, das
nach VHDL-Verhaltensbeschreibung umsetzt, kann ich das. Für alle
Schritte danach benötige ich zumindest eine relevante Anzahl an Nutzern
als Basis.
> Und: 'Confidence Level' am Hype/Google-Statistiken festzuknuepfen ist> ein ziemlicher Holzweg :-) Kann man sehr gut bei div. Hacks wie (n)migen> sehen.
Mit google-Statistiken hat das nichts zu tun. Vivado und Matlab haben
einfach mehr Nutzer als Dein Tool.
> Was nicht heissen soll, dass das Ding bugfrei ist, da, wie gesagt,> Neuaufwasch.
Dass (noch) bugs in Deinem Tool drin sein mögen, ist gar nicht das
Problem. Das ist bei den anderen ja auch der Fall.
Lars R. schrieb:> Hast Du bitte ein> konkretes Beispiel für mich?
Binder-Button (launch binder) im README anklicken, warten, Notebooks
durchspulen, z.b. Barrelshifter.
> Klar. Und mich interessiert, wofür ich haften kann. Bei einem Tool, das> nach VHDL-Verhaltensbeschreibung umsetzt, kann ich das
Dann solltest du das hiermit koennen, wenn du der Synthese traust (ich
aus guten Gruenden bei Vivado nicht). Weiterhin also:
S. R. schrieb:> Garantiert dir Xilinx, dass Vivado dein VHDL oder Verilog fehlerfrei> synthetisiert? Meines Wissens eindeutig nicht. Für HLS gilt das noch> viel mehr.
Unterschreibe ich mehrfach.
Im obigen Container steckt GHDL, bis und mit VHDL-Zwischenschicht kannst
du also funktional nach strengem VHDL-Standard verifizieren. Das klappt
genauso mit einer Netzliste als VHDL-Ausgabe, wenn die Primitiven
verifiziert sind und nicht nur als black box vorliegen.
> Mit google-Statistiken hat das nichts zu tun. Vivado und Matlab haben> einfach mehr Nutzer als Dein Tool.
Na und? Der Vergleich hinkt.
Wenn du der Meinung bist, dass Nutzerzahlen oder grosse Firmen fuer
Robustheit sprechen und lieber mit Matlab/Vivado arbeiten willst, tu'
das. Ich erinnere mal an obigen Disclaimer betr. produktivem Einsatz.
Lars R. schrieb:>> Und: 'Confidence Level' am Hype/Google-Statistiken festzuknuepfen>> ist ein ziemlicher Holzweg :-) Kann man sehr gut bei div. Hacks>> wie (n)migen sehen.> Mit google-Statistiken hat das nichts zu tun. Vivado und Matlab> haben einfach mehr Nutzer als Dein Tool.
Wenn dein Maßstab die Größe der Community bzw. die Anzahl der Nutzer
ist, dann darfst du schlicht kein Produkt eines Nichtweltmarktführers
einsetzen.
In deinem Weltbild gibt es schlicht keine nutzbaren Tools jenseits von
Matlab oder Vivado, also brauchst du dich mit denen auch nicht näher
befassen. Ganz einfach.
Und ich erinnere mich düster an eine Diskussion hier, wo jemand das
Thema "not suitable for medical or military use" bei Vivado (oder war's
ein Äquivalent?) hinterfragt hat. Die garantieren nämlich auch für nix.
S. R. schrieb:> Lars R. schrieb:> Wenn dein Maßstab die Größe der Community bzw. die Anzahl der Nutzer> ist, dann darfst du schlicht kein Produkt eines Nichtweltmarktführers> einsetzen.>> In deinem Weltbild gibt es schlicht keine nutzbaren Tools jenseits von> Matlab oder Vivado, also brauchst du dich mit denen auch nicht näher> befassen. Ganz einfach.
Das stimmt überhaupt nicht. Ich setze viele Open-Source-Tools ein, die
ich zwei Beiträge weiter oben auch aufgezählt hatte
Beitrag "Re: HDL in Python / MyHDL die Zweite (unfertig)"
Auch MyHDL benutze ich bisher immer wieder, obwohl es nun wirklich keine
große Community hat. Nur muss ich mich bei MyHDL weniger auf die
Fehlerfreiheit verlassen, weil MyHDL eine lesbare, nahezu
handgeschriebene VHDL-Verhaltensbeschreibung erzeugt.
Nur wurde ich aus irgend einem Grund in den letzten zwei Beiträgen auf
die kommerziellen Tools reduziert.
Das hier diskutierte Tool, dass auf eine nicht-lesbare VHDL-Beschreibung
(eben nicht so wie MyHDL) umsetzt, hat eine Nutzerbasis von 1-2. Was ist
daran so schwer zu verstehen, dass das ein Himmelweiter Unterschied
(10**4 bis 10**7) ist im Vergleich zu anderen Tools, open-source wie
auch closed-source?
Lars R. schrieb:> Das hier diskutierte Tool, dass auf eine nicht-lesbare VHDL-Beschreibung> (eben nicht so wie MyHDL) umsetzt, hat eine Nutzerbasis von 1-2. Was ist> daran so schwer zu verstehen, dass das ein Himmelweiter Unterschied> (10**4 bis 10**7) ist im Vergleich zu anderen Tools, open-source wie> auch closed-source?
Ich rate zu genauerem Lesen und einem Faktencheck, bevor du wiederholt
falsche Behauptungen aus der Gebetsmuehle abspulst.
Die hierarchische VHDL-Ausgabe ist hier gegenueber der klassischen
flachen Konversion von myHDL deutlich lesbarer, u.a. da die Interfaces
erhalten werden, ueberfluessige/fehleranfaellige
bool<->std_logic-Konversion sowie 'random' name mangling wegfaellt (plus
Support fuer records, usw.).
NB: Ich habe durchaus die Moeglichkeit, die Nutzerzahlen zu erfassen.
Solange der Anteil der User mit ausgepraegter Anspruchshaltung klein
bleibt, passt's, der Rest geht nicht mal github et al etwas an.
Martin S. schrieb:> Lars R. schrieb:>> Das hier diskutierte Tool, dass auf eine nicht-lesbare VHDL-Beschreibung>> (eben nicht so wie MyHDL) umsetzt, hat eine Nutzerbasis von 1-2. Was ist>> daran so schwer zu verstehen, dass das ein Himmelweiter Unterschied>> (10**4 bis 10**7) ist im Vergleich zu anderen Tools, open-source wie>> auch closed-source?>> Ich rate zu genauerem Lesen und einem Faktencheck, bevor du wiederholt> falsche Behauptungen aus der Gebetsmuehle abspulst.
Bei MyHDL werden Bezeichner nahezu 1:1 umgesetzt. Der Code wird nahezu
Zeile für Zeile zu einer VHDL-Beschreibung übersetzt.
Die Hierarchie bei MyHDL ist flach, dafür ist Hierarchie in den Namen
der Bezeichner kodiert. Mit einigem Umstand bekommt auch aus MyHDL eine
Hierarchie heraus.
Bei Deinem Ansatz habe ich noch keine VHDL-Verhaltensbeschreibung
gesehen.
Es kann sehr gut sein, dass ich diese übersehen habe. Würdest Du bitte
etwas VHDL hier posten?
Zum Shifter-Beispiel habe ich bei Deinem Ansatz nur das Folgende gesehen
Das ist sehr weit entfernt von einer lesbaren
VHDL-Verhaltensbeschreibung so wie MyHDL sie erzeugt.
1
architectureMyIRLoftop_bsis
2
--Localtypedeclarations
3
--Signaldeclarations
4
signals_0f22:unsigned(15downto0);
5
signalclk_d36e:std_ulogic:='0';
6
signals_025e:std_ulogic;
7
signals_0edc:unsigned(15downto0);
8
signals_7c99:unsigned(3downto0);
9
begin
10
--Instancebarrel_shifter
11
inst_barrel_shifter_0:entitywork.barrel_shifter
12
portmap(
13
clk=>clk_d36e,
14
ce=>s_025e,
15
val=>s_0edc,
16
s=>s_7c99,
17
result=>s_0f22
18
);
19
20
CLKGEN_73d5:
21
clk_d36e<=notclk_d36eafter2ns;
22
23
24
stim:
25
process
26
begin
27
--UnrollIteratoritem:(57005,8,44288):{
28
29
s_025e<='0';
30
s_7c99<=to_unsigned(8,4);
31
s_0edc<=to_unsigned(57005,16);
32
waituntilrising_edge(clk_d36e);
33
s_025e<='1';
34
waituntilrising_edge(clk_d36e);
35
waituntilrising_edge(clk_d36e);
36
print("0x"&hstr(s_0f22));
37
assert(s_0f22=44288)
38
report"Failed in /tmp/ipykernel_35/1235503122.py:top_bs():36"severityfailure;
39
40
s_025e<='0';
41
s_7c99<=to_unsigned(15,4);
42
s_0edc<=to_unsigned(36609,16);
43
waituntilrising_edge(clk_d36e);
44
s_025e<='1';
45
waituntilrising_edge(clk_d36e);
46
waituntilrising_edge(clk_d36e);
47
print("0x"&hstr(s_0f22));
48
assert(s_0f22=32768)
49
report"Failed in /tmp/ipykernel_35/1235503122.py:top_bs():36"severityfailure;
Anmerkung:
Einige der von MyHDL eingefügten bool-Konvertiertierungen gehen darauf
zurück, dass MyHDL noch nicht nach VHDL-2008 übersetzt. Mit einer
anderen Notation in Python kann man viele davon vermeiden.
@Lars: Ich werde hier nicht mit VHDL den Thread zumuellen. Es gibt
genuegend Beispiele im Binder, die eine VHDL-Beschreibung ausgeben.
Nebenbei: Die Top-Level-Signale (und interne prozedurale) kriegen einen
UUID-Bezeichner, wenn man ihnen nicht explizit einen Namen gibt. Falls
das das Kriterium fuer 'Lesbarkeit' waere.
Laesst sich trotzdem alles reproduzierbar tracen und die Signalnamen
oder Hierarchiereihenfolge aendern sich nicht nach Belieben (aufgrund
'dict'-Strukturen) wie bei myHDL. Name-Mangling in der Art ist bei
komplexen Designs ein no-go, geht bis zum Absturz der Tools aufgrund zu
langer Identifier.
Martin S. schrieb:> @Lars: Ich werde hier nicht mit VHDL den Thread zumuellen. Es gibt> genuegend Beispiele im Binder, die eine VHDL-Beschreibung ausgeben.> Nebenbei: Die Top-Level-Signale (und interne prozedurale) kriegen einen> UUID-Bezeichner, wenn man ihnen nicht explizit einen Namen gibt. Falls> das das Kriterium fuer 'Lesbarkeit' waere.
Falls ich es richtig verstehe, so wird in
https://github.com/hackfin/myhdl.v2we/blob/master/example/gray_counter.ipynb
aus
flags = [ Signal(bool(), name="flags%d" % i) for i in range(n + 1) ]
Folgendes:
signal flags0 : std_ulogic;
signal flags1 : std_ulogic;
signal flags2 : std_ulogic;
signal flags3 : std_ulogic;
signal flags4 : std_ulogic;
Was ist die Motivation, dies so zu notieren und einzelne Signale mit
explizit oder implizit vergebenen Namen zu erzeugen? Warum wird eine
Liste von bool nicht zu unsigned, std_logic_vector oder array of
std_logic?
Wird array unterstützt?
Lars R. schrieb:> Was ist die Motivation, dies so zu notieren und einzelne Signale mit> explizit oder implizit vergebenen Namen zu erzeugen?
Das liegt an der Natur von Python, mit Referenzen zu arbeiten, so kann
ein Python-Objekt nicht wissen, welchen Namen es im lokalen Namespace
hat. Ist ja auch nicht eindeutig, s.u.:
1
a = Signal(bool())
2
b = a # Referenz auf a
3
...
4
5
inst = unit(b)
Wie soll jetzt das Signal im Transpilat (VHDL) heissen?
Sobald das Signal lokal innerhalb einer Funktion definiert wird oder an
ein Funktionsinterface weitergereicht wird, kann es (lokal) den Namen
uebernehmen.
NB: Ausfuehrung versus AST-Translation.
Lars R. schrieb:> Warum wird eine> Liste von bool nicht zu unsigned, std_logic_vector oder array of> std_logic?
Weil es ein Array von Signalen ist, kein Signal eines Array-Datentyps.
Weiterfuehrende Stichworte: myHDL Shadow-Signals (obsolet), den
(verbotenen) Klassiker
Martin S. schrieb:> Zum Ansatz, siehe> Beispiel im Container (RGB->YUV-Pipeline).
Na die hätte man auch aus der Hand direkt hinschreiben können. Was mich
und meine Anwendungsfälle angeht, habe ich eher Rechnenpipes im Kopf,
die aus der Formel direkt den Code (MIT timing, delays) erzeugt. Da habe
ich bisher wenig gesehen, Auch sonst nicht.
Martin S. schrieb:> Lars R. schrieb:>> Was ist die Motivation, dies so zu notieren und einzelne Signale mit>> explizit oder implizit vergebenen Namen zu erzeugen?>> Das liegt an der Natur von Python, mit Referenzen zu arbeiten, so kann> ein Python-Objekt nicht wissen, welchen Namen es im lokalen Namespace> hat. Ist ja auch nicht eindeutig, s.u.:>
1
> a = Signal(bool())
2
> b = a # Referenz auf a
3
> ...
4
> inst = unit(b)
5
>
>> Wie soll jetzt das Signal im Transpilat (VHDL) heissen?VHDL hat keine Referenzen. Meine Erwartungshaltung wäre, dass b nicht
für übersetzungsrelevante Code-Zeilen verwendet wird. Falls doch, dann
sollte es eine Fehlermeldung geben.
Falls b ein Signal werden soll, dann gibt es zwei Möglichkeiten:
a) "b" als Signal erstellen und im kombinatorischen Prozess a auf b
zuweisen. Das funktioniert auch mit MyHDL.
b) Eine neue, bisher nicht funktionierende Notation: b = Signal(a),
falls das nicht bereits die Funktion von ShadowSignal ist. Behelfsweise
funktioniert ggf. b=concat(a) ?
Die explizite Vergabe von Signalnamen nutze ich unter MyHDL nur als Hack
für ausgefallene Funktionalität. Normalerweise möchte ich in VHDL den
Signalnamen aus dem Python-Code wiederfinden. Wenn MyHDL Hierarchien von
Haus aus unterstützen würde, so wären die Signalnamen auch kurz und
eindeutig. Inzwischen habe bzgl. der Übersetzung den für die
Instantiierung erforderlichen Code zu ca. 50% da stehen. Letztlich fehlt
nur für jede Instantiierung der port map und ein separater
Übersetzungsvorgang für jeden Block.
> Lars R. schrieb:>> Warum wird eine>> Liste von bool nicht zu unsigned, std_logic_vector oder array of>> std_logic?>> Weil es ein Array von Signalen ist, kein Signal eines Array-Datentyps.
Aus einer Liste von intbv wird doch ein einziges Signal als array(?)
Aber aus einer Liste von bool wird für jedes Element der Liste ein
eigenes VHDL-Signal erzeugt(?)
> Weiterfuehrende Stichworte: myHDL Shadow-Signals (obsolet), den> (verbotenen) Klassiker>
1
> s.next[i] = v
2
>
> und generell die Stolperfallen bei solchen partiellen Zuweisungen.
Ich glaube, unter MyHDL 0.7 oder 0.8 hat das nicht funktioniert. Mit
0.10 und 0.11 komme ich diesbezüglich zurecht.
Wenn man schon
1
s.next = v
schreibt, dann kann man auch
1
s.next[i] = v
und
1
s[i].next = v
schreiben. Das ist konsistent.
Thema Interfaces:
MyHDL unterstützt Interfaces, dh. Klassen von Signalen. Eine weitere
Schachtelung, dh. Klassen von Klassen von Signalen, wird jedoch nicht
unterstützt.
MyHDL errät die Portrichtung aus den Signalzuweisungen. Selten, in
speziellen Fällen funktioniert es nicht und man muss nachhelfen.
Bei Deinem Ansatz wird die Portrichtung mitdefiniert. Das bedeutet dann
aber auch, dass man Interfaces bis zu dreimal definieren muss:
1. Komponente a
2. Komponente b (Gegenstück zu a)
3. Bei Verwendung als Signal innerhalb der Architecture
Ist das korrekt?
Martin S. schrieb:> Lass mich raten: Vorzeichenbehaftete Erweiterungen (Signed extensions)?> Das ist bei myHDL ein Trauerspiel, der Bug (nur VHDL-Ausgabe) wird von> den Maintainern geflissentlich (seit rund 10 Jahren) ignoriert.
Hat etwas gedauert, mußte noch einmal im Archiv suchen. Muß wohl das
gewesen sein, da mit dem Sign Bit was nicht stimmte.
Ich hatte das nicht mehr weiterverfolgt und die Arithmetik in VHDL
implementiert. Das lief auf Altera korrekt im FPGA.
Lars R. schrieb:> Falls b ein Signal werden soll, dann gibt es zwei Möglichkeiten:
Nee, soll es nicht. Es ist in Python ja eine Referenz auf das gleiche
Objekt und soll in der HDL nichts anderes beschreiben.
Das VHDL-Aequivalent waere allerhoechstens noch ein Alias. Da aber Code
ausgefuehrt wird, muesste das explizit erzeugt werden, z.B:
1
b = a.make_alias()
> Aus einer Liste von intbv wird doch ein einziges Signal als array(?)> Aber aus einer Liste von bool wird für jedes Element der Liste ein> eigenes VHDL-Signal erzeugt(?)
Probier's durch, ein Listengenerator wie folgt erzeugt fuer jedes
Element ein Signal (sofern benutzt), Wiretyp egal.
1
a = [ Signal(intbv()[5:]) for _ in range(3) ]
Ein explizites Array/List of Signals ist wiederum ein erweiterter
Datentyp.
Zum Thema `s.next[i] = v` in myHDL: Gab da schon lange Diskussionen, da
`.next` intern ein Setter ist (sofern `s` eine Signal-Instanz), ist es
vom funktionalen Aspekt her ein Graus, das nochmal zu slicen. Man kann
auch nicht `s[i].next = v` nehmen, da ein Slice eines Signals kein
Signal mehr ist. Das wiederum geht dann nur bei Signal-Arrays. Also,
konsistent ist das nicht wirklich.
> Thema Interfaces:> MyHDL unterstützt Interfaces, dh. Klassen von Signalen. Eine weitere> Schachtelung, dh. Klassen von Klassen von Signalen, wird jedoch nicht> unterstützt.
Moment. Interface = [ Ports, Parameter ], nicht zwingend eine Klasse.
> Bei Deinem Ansatz wird die Portrichtung mitdefiniert. Das bedeutet dann> aber auch, dass man Interfaces bis zu dreimal definieren muss:> 1. Komponente a> 2. Komponente b (Gegenstück zu a)> 3. Bei Verwendung als Signal innerhalb der Architecture>> Ist das korrekt?
Wenn du eine Container-Klasse (`@bulkwrapper(t, TYPE="inout")`) meinst:
je Richtung im Interface von [a, b], also 2x. Wenn solche Szenarien mit
Sender und Empfaenger oefters auftreten, macht eine Spezifikation
`MyContainerClass.invert()` allenfalls Sinn.
Sonst: unidirektionale BulkSignal-Typen nutzen, wo die Richtung auf
Interface-Level (versus im Container vergraben) klar definiert ist,
entsprechend den VHDL records.
Martin S. schrieb:>> Aus einer Liste von intbv wird doch ein einziges Signal als array(?)>> Aber aus einer Liste von bool wird für jedes Element der Liste ein>> eigenes VHDL-Signal erzeugt(?)>> Probier's durch, ein Listengenerator wie folgt erzeugt fuer jedes> Element ein Signal (sofern benutzt), Wiretyp egal.>
1
> a = [ Signal(intbv()[5:]) for _ in range(3) ]
2
>
>> Zum Thema `s.next[i] = v` in myHDL: Gab da schon lange Diskussionen, da> `.next` intern ein Setter ist (sofern `s` eine Signal-Instanz), ist es> vom funktionalen Aspekt her ein Graus, das nochmal zu slicen. Man kann> auch nicht `s[i].next = v` nehmen, da ein Slice eines Signals kein> Signal mehr ist. Das wiederum geht dann nur bei Signal-Arrays. Also,> konsistent ist das nicht wirklich.
In MyHDL sind es 3 Signale, auf die aber nur über a zugegriffen
wird/werden sollte. In der VHDL-Übersetzung ist es dann ein Signal. Mit
der Python-Liste wird das VHDL-array realisiert.
Auf das 0te Bit des letzten Array-Elements wird somit zugewiesen mit:
1
a[2].next[0] = x
Das funktioniert wunderbar. Es ist konsistent zur Python-Syntax und der
übersetzte VHDL-Code ist konsistent. Würde MyHDL rekursiv auswerten, so
wären auch Listen von Listen möglich.
Ein Problem mit "nochmal slicen" sehe ich nicht. Ein Problem ist, dass
für den Index nur Konstanten akzeptiert werden und keine anderen Typen,
wie zum Beispiel slice. Das ist einfach noch nicht (fertig)
implementiert.
> Ein explizites Array/List of Signals ist wiederum ein erweiterter> Datentyp.
Attraktiv an MyHDL war für mich, dass ich eine Hardwarebeschreibung in
Python mit weniger Code und weniger Syntax-Zucker als in VHDL darstellen
kann und dennoch schnell und einfach vorhersehen kann, welche
VHDL-Beschreibung mit welchen Signalen dabei heraus kommt.
Dabei wurden die Unzulänglichkeiten von VHDL-93 abgemildert. Deshalb
konvertiert MyHDL auch so viel zu bool in der VHDL-Übersetzung.
Mit VHDL-2008 sind jedoch die Bool-Konvertierung und auch andere Tricks
gar nicht mehr erforderlich. Daran sieht man, wie wenig sich bei MyHDL
noch tut.
MyHDL habe ich als Pythonisierung von VHDL gesehen.
Dem Prinzip "Übersetzen von Python zu VHDL" steht es entgegen, wenn man
zusätzlich zum Python-Variablennamen noch VHDL-Signalnamen explizit
vorgibt, in die der Python-Variablenname übersetzt werden soll
[Anmerkung1]. Das ist dann keine Übersetzung von Python zu VHDL mehr.
Vielmehr wird dann in Python Meta-artig beschrieben, wie VHDL erzeugt
werden soll; inklusive Generatoren, die loop-unroll into VHDL-Code
machen. Das war/ist nicht der MyHDL-Ansatz, sondern eher der Ansatz von
migen.
[Anmerkung1: Bei Kollisionen im Namensraum darf man dann heraus finden,
welcher explizit vorgegebene, dynamisch erzeugte Name mit welchem
anderen Namen kollidiert.]
Mir persönlich geht bei MyHDL bereits das automatisierte Resetten zu
weit, zumal es viele andere Baustellen gibt:
. Hierarchie
. Einem Signal eine Konstante zuweisen
. Die Art und Weise, wie Konstanten zu VHDL übersetzt werden
. Eine Klasse Generics für die Argumente, die tatsächlich Generics
werden könnten
Bzgl. Deinem Ansatz: Wenn ich mir nicht mehr sicher bin, welche
VHDL-Verhaltensbeschreibung genau heraus kommt, dann muss ich
prinzipiell viel eher im Entwicklungsprozess das VHDL-Ergebnis anschauen
und auch **mit dem VHDL-Simulator** simulieren. Für mich stellt sich
dann jedoch die Frage, warum ich es überhaupt noch in Python notiere. So
viel weniger Code ist es gerade bei Deinem Ansatz nicht mehr und
übersichtlicher wird es mit Vergabe expliziter Namen für das
Übersetzungsergebnis und Generator-Funktionalitäten auch nicht. Da kann
ich dann auch gleich in VHDL notieren. Oder eben in C/migen/...
>> Thema Interfaces:>> MyHDL unterstützt Interfaces, dh. Klassen von Signalen. Eine weitere>> Schachtelung, dh. Klassen von Klassen von Signalen, wird jedoch nicht>> unterstützt.>> Moment. Interface = [ Ports, Parameter ], nicht zwingend eine Klasse.>>> Bei Deinem Ansatz wird die Portrichtung mitdefiniert. Das bedeutet dann>> aber auch, dass man Interfaces bis zu dreimal definieren muss:>> 1. Komponente a>> 2. Komponente b (Gegenstück zu a)>> 3. Bei Verwendung als Signal innerhalb der Architecture>>>> Ist das korrekt?>> Wenn du eine Container-Klasse (`@bulkwrapper(t, TYPE="inout")`) meinst:> je Richtung im Interface von [a, b], also 2x.
Demzufolge auch ein drittes Mal, wenn ich es als Signal innerhalb einer
architecture benötige. Bei MyHDL muss man es nur einmal notieren. Denn
wenn man die Interface-Klasse als Port(s) benutzt, dann sucht MyHDL die
Richtung automatisch heraus, wie auch bei den einfachen Ports.
> Wenn solche Szenarien mit> Sender und Empfaenger oefters auftreten, macht eine Spezifikation> `MyContainerClass.invert()` allenfalls Sinn.> Sonst: unidirektionale BulkSignal-Typen nutzen, wo die Richtung auf> Interface-Level (versus im Container vergraben) klar definiert ist,> entsprechend den VHDL records.
Ja, records unterstützt MyHDL nicht und es wäre ganz nett, wenn die
Interface-Klassen für Signale in Architectures zu records übersetzt
würden. Aber da gäbe es noch genügend andere Baustellen.
Mit VHDL-2019 wird das Thema records in ports ohnehin erledigt sein.
@Lars: Du verstrickst dich hier wieder etwas in Nebendetails.
Zu den relevanten Punkten:
1. Neuere VHDL-Standards spielen beim Transfer zur RTL eine
untergeordnete Rolle. Sie muessen einfach vom Synthesetool richtig
umgesetzt werden (Fehlanzeige: Vivado und VHDL-2008). Deswegen: Interne
strukturelle Knackpunkte wie bool<->std_logic auf die Target-HDL
umzuwaelzen ist eine schlechte Idee (VHDL ist nicht der einzige
Target..).
Die IR erlaubt schlicht keine logischen booleans mehr in
HDL-Expressions. (Python-Preisfrage: warum?). myHDL Code wird
entsprechend so konvertiert.
2. Thema s.next[i]: Lies oben nochmal zum Stichwort 'Setter'. Wer sich
mit den Interna beschaeftigt, sieht sehr schnell, dass das zwar geht,
aber hochgradiger Murks ist.
Da passiert naemlich intern sowas wie:
1
s.next_getter()[i] = v
somit findet eine Manipulation eines Wertes statt, der eigentlich
bewacht (protected) sein sollte. Der Setter bekommt also nicht mit, wenn
ein Teilelement veraendert wird. Im myHDL-Simulator ist das 'nur' mit
intbv und erweiterten Typen problematisch, in verbesserten Ansaetzen
('X'/'U' support, etc.) so ziemlich sinnfrei, erst recht bei der
Transpilierung in RTL/HDL, etc.
Setter-kompatibel (und logisch) waere in deinem Beispiel:
1
a[2][0].next = v
wenn man (konsequenterweise) davon ausgeht, dass ein Slice eines Signals
wiederum ein Signal ist (und so muss es im ereignisgetriebenen Modell
auch sein).
Bei v2we wird die Notation schlicht nicht unterstuetzt, nur bei
Variablen und (custom) Bus-Signaltypen ist in der IR partielle Zuweisung
erlaubt.
3. Die Interface-Architektur in der IRL ist auf dem besten Weg zu einer
strengen Typisierung, die alte Kuh des fehleranfaelligen I/O-Erratens
von myHDL wird definitiv geopfert. Deswegen muss man auch die Richtung
im Interface angeben. Wie du auf dreimal kommst, ist mir schleierhaft,
ist aber auch irrelevant. Bitte die konkreten Beispiele bzgl.
Klassen-Migration von myhdl 'legacy' studieren (classes.ipynb).
Grundsaetzlich lassen sich all die Aspekte besser verstehen, wenn man
sich dran erinnert: Die IRL setzt funktionale Programmierprinzipien (so
weit mit Python moeglich) um und es wird immer Code ausgefuehrt.
Insofern: Ja, es wird per IRL-Layer meta-programmiert anstatt
AST-Translation betrieben. Steht auch schon ein paar mal explizit
geschrieben, und ist deswegen auch eher was fuer Python-Spezis.
So, und jetz muss ich hier erst mal die Bremse ziehen. Der noch offene
"Supportkanal" sind konkrete Testcases als Notebook (per github gist,
etc.). Fuer das Spiel 'Devils Advocate' auf der Basis obskurer Annahmen
ist mir die Zeit zu schade.
Moin,
es gibt mal wieder ein groesseres Update hierzu:
- Umstieg auf Python 3.10 und JupyterLab (etwas brauchbarer im Sinne
einer 'IDE')
- Interface-Typechecking nun 'strikte': Fehler anstatt Warnung.
- Mehr Anwendungs-Szenarien zu den Interface-Klassen (a la VHDL-2019
'mode views') und Type-Checking generell
- Saeuberung von Boolean und arithmetischen Stolperfallen
Die bisherigen MyHDL-Signal-Klassen muss man entsprechend dekorieren
(genau einmal), die Richtung gibt man im Interface per Type-Hint
`.reverse()` entsprechend an.
Ein paar Generatoren-Erweiterungen (wie prozedurale CRC-Logic,
SoC-Register-Decoder, etc.) sind als Beispiele hinzugefuegt worden.
Der obligatorische Disclaimer: Obwohl sich das Ganze deutlich auf einem
stabilen Energieminimum einpendelt (frei nach Heisenbergscher
Unschaerfe), sollte man nur unter Vorbehalt allzu komplexe
MyHDL-Hinterlassenschaften portieren, da einige Konstrukte definitiv
nicht mehr unterstuetzt werden.
Noch ein Update, dann bleibt erst mal alles in einem relativ
stationaeren Zustand:
- Downgrade auf Python 3.9
- Yosys-Target: Direkte Synthese in RTLIL-Primitiven und rudimentaere
Anbindung an das CXXRTL-Simulator-Backend
- Anzeige der RTL im 'alten' yosys-Schema ('dot')
- Co-Simulation der synthetisierten Logik gegen einen externen
Python-Stimulus
- Einige wenige Memory-Inferenz-Szenarien abgedeckt (im Sinne 'works for
me')
Zur Yosys-Seite: Inzwischen laesst sich deren Synthese fuer einige
komplexere Designs (z.B. einen kompletten uC SoC mit Memory) verwenden,
es ist also nicht mehr nur zum Spielen. Wenn man die Simulationsmodelle
der Primitiven hat, kann man sich weitestgehend alle Schritte in der
Synthese bis zum Mapping auf das Target verifizieren, oder der Community
einen virtuellen Chip legal als Python-DLL zum Selber-Ansteuern liefern.
Der Teufel mag aber im Detail stecken, deswegen: A priori immer noch
fuer den akademischen Einsatz (zuhause).
Hi, gibt es hier noch einen Entwicklung? Wir benutzen schon myhdl und
nmigen aber haben diverse Probleme (hierarchy bei myhdl für grosse
Projekte und viele workaround, Bugs nicht gefixt, usw)
Mit Notebook online kann ich leider nicht arbeiten. Also ein paar
Fragen:
Gibt es in Zukunft ein Paket für Windows?
Gibt es Beispielprojekte ohne jupyter?
Kann man System verilog in hierarchy ausgeben?
Im Github gab es in den letzten Monaten immer wieder mal einen Commit,
aber anscheinend nur Fixes. Da geht wohl nicht mehr viel. War eine
exezellente Idee, ist aber leider im Sande verlaufen.
Aber wer weiß. Totgesagte leben angeblich länger. Vielleicht holt mal
jemand das Konzept aus der Versenkung und macht ein Tool für den
Produktiveinsatz daraus.
vancouver schrieb:> mein Post bezog sich auf das ursprünglich MyHDL.
Auf MyHDL an sich, oder die Portierung von Strubi?
Wäre vlt mal nett wenn man die Strukturen mal etwas transparenter machen
würde. Das ist mit die größte Hürde, nämlich die Unsicherheit
potenzieller Nutzer, viel Zeit zu verschwenden, weil sie den Wert nicht
erkennen.
FPGA-Experte schrieb im Beitrag #7330373:
> Auf MyHDL an sich, oder die Portierung von Strubi?
Ersteres. Ich hatte nicht mehr auf dem Schirm, dass es in diesem Artikel
um die Portierung von Strubi ging.
Moin,
vorweg: mit dem original-myhdl Projekt hat das ganze nichts mehr zu tun,
die letzten Faeden (intbv) wurden soweit gekappt. An der myhdl-Front ist
die Entwicklung kaum noch wartbar bis tot, bzw. werden von den noch
motivierten (produktiven) Entwicklern vor allem in-house Forks
unterhalten. Als Community-Projekt leider schon fruehzeitig gescheitert,
siehe alte myhdl-Maillinglist.
Nichtsdestotrotz ein sehr brauchbares Konzept (gewesen).
cerbi schrieb:> Hi, gibt es hier noch einen Entwicklung? Wir benutzen schon myhdl> und> nmigen aber haben diverse Probleme (hierarchy bei myhdl für grosse> Projekte und viele workaround, Bugs nicht gefixt, usw)
Am Kernel ('Cyrite'/MyIRL) wird nicht mehr geschraubt, weitere
MyHDL-Emulation macht fuer mich keinen Sinn mehr. Das bleibt also die
naechsten Jahre so, modulo Bugs, die noch auftauchen sollten. Ansonsten
gibt es 'migration notes' fuer alten myhdl-Code und die Emulation. Das
Hauptmerkmal dabei ist die Typenstrenge ('annotation' von in/out) fuer
Hierarchien.
> Mit Notebook online kann ich leider nicht arbeiten. Also ein paar> Fragen:>> Gibt es in Zukunft ein Paket für Windows?
Den Docker-Container kannst du grundsaetzlich auch mit den Docker-Utils
fuer Windows lokal laufen lassen. Andere Pakete sind nicht angedacht.
> Gibt es Beispielprojekte ohne jupyter?
Die Beispiele in den Notebooks lassen sich 1:1 extrahieren und auch per
Konsole starten. Ausnahme: Waveformen und RTL-Anzeigen.
Einen abgespeckten RISC-V koennte ich allenfalls zur Verfuegung stellen.
Fehlt nur grad die Zeit.
> Kann man System verilog in hierarchy ausgeben?
Da wurde mal was entwickelt, aber nicht veroeffentlicht. Das Problem
dabei sind jeweils toolspezifische Anforderungen, das alles universell
zu machen ist zuviel Arbeit. Ansonsten: von Verilog-Konverterklasse
ableiten und selber seine Sachen einbauen. SV macht eigentlich IMHO nur
fuer erweiterte Testbenches Sinn.
Martin S. schrieb:> An der myhdl-Front ist> die Entwicklung kaum noch wartbar bis tot,
Leider erwartbar! Solche tools brauchen Support ohne Ende von vielen und
guten Leuten, die richtig Zeit haben. Gute Leute sind aber ausgebucht
und haben keine Zeit mehr für open source. Man muss auch heute schauen,
wie man seine Gasrechnung bezahlt und mehr Arbeitszeit unterbringt. Hier
beim THW und der Feuerwehr kommen immer weniger zum freiwilligen Dienst,
weil sie Überstunden machen oder am Wochenende arbeiten, um ihre
Rechnungen zu bezahlen.
Leider ziemlicher Unsinn. Dann wäre die gesamte Open Source Szene tot,
und die ist lebendiger als je zuvor. Schau dir mal die Beiträge der
letzten FOSDEM an, dann hast du einen guten Überblick, was alleine bei
OS-Tools für Hardwaredesign gerade so alles läuft.
Experte schrieb:> Leider erwartbar! Solche tools brauchen Support ohne Ende von vielen und> guten Leuten, die richtig Zeit haben. Gute Leute sind aber ausgebucht> und haben keine Zeit mehr für open source.
Trifft m.E. nicht zu.
Die investierte Zeit amortisiert sich je nach Fokus auch sehr schnell,
kann man am gesamten Python-Oekosystem gut selber 'messen'.
Obwohl OpenSourcing im Sinne der GPL bei einigen Kunden sehr unbeliebt
ist, sind das bei MyHDL eher andere Gruende (wie oben angeklungen). Was
man vielleicht dazu sagen sollte: MyHDL ist als HDL **semantisch**
schick designt (das beizubehalten lohnt sich), dafuer steckt eine Menge
Murks in der Architektur, die das Aufbohren sehr aufwendig macht. Haben
sich einige gute Leute daran die Nase blutig gehauen, u.a. auch wegen
des ignoranten Habitus der ueber die Jahre wechselnden Maintainer.
In der yosys-OS-Community laeuft in der Tat eine Menge, ich wuerde
inzwischen behaupten, dass man mit gut ausgewaehlten Setups produktiver
ist als mit den Herstellertools.
Einige Korrekturen sollte ich wohl mal noch anbringen:
> https://github.com/hackfin/myhdl.v2we
ist jetzt:
https://github.com/hackfin/cyrite.howto> Aber Achtung: Nur was fuer Python-Enthusiasten (bevor das Geunke aus der> konservativen HDL-Ecke losgeht). Nicht fuer den produktiven Einsatz!
Revision dieser Aussage: Man kann es jetzt produktiv einsetzen, da
einige neue Verifikationsmethoden dazugekommen sind, die nunmehr als
'stabil' gelten. Dito gilt fuer die API. Die yosys-Anbindung ist wegen
der knoettrigen API noch experimentell zu sehen, aber CXXRTL
Co-Simulation hat sich ueber die Jahre ganz gut bewaehrt. Einige
Beispiele kommen allenfalls im Herbst mal dazu, wie virtualisierte
[C-G]PU cores, die 'closed source' co-simuliert werden koennen.
Antti L. schrieb:> Dumme frage: warum heisst repo: cyrite.howto ?> ist irgendwo geheime repo namens: cyrite auch?
cyrite.howto ist die weitergefuehrte Dokumentation, die aus den
Emulationsexperimenten mit myhdl(v2we) hervorging. Dahinter steckt der
fertig gebaute cyrite-Docker-Container, zu dem es zum jetzigen Zeitpunkt
kein oeffentliches Source-Repo gibt. Also, ja, quasi 'geheim', somit
gilt das Projekt nicht als vollstaendige OpenSource.
Martin S. schrieb:> Antti L. schrieb:>> Dumme frage: warum heisst repo: cyrite.howto ?>> ist irgendwo geheime repo namens: cyrite auch?>> cyrite.howto ist die weitergefuehrte Dokumentation, die aus den> Emulationsexperimenten mit myhdl(v2we) hervorging. Dahinter steckt der> fertig gebaute cyrite-Docker-Container, zu dem es zum jetzigen Zeitpunkt> kein oeffentliches Source-Repo gibt. Also, ja, quasi 'geheim', somit> gilt das Projekt nicht als vollstaendige OpenSource.
Wird das Project irgendwann open-source?
mit einem geheimen docker container will keiner arbeiten...
Antti L. schrieb:> Wird das Project irgendwann open-source?>
Denke kaum, stand bisher auch nicht zur Diskussion, da es nur
Mehraufwand generieren wuerde.
> mit einem geheimen docker container will keiner arbeiten...
Mit Vivado will auch keiner arbeiten :-)
Sarkasmus beiseite: Geheim ist am Container nichts, aber einige cyrite
Kernelemente bleiben b.a.w. closed source. Die Zielgruppen sind schlicht
nicht Entwickler, die sich ihre Software selber bauen wollen...
A priori ist der Container fuer die Ausfuehrung 'as is' im Binder
gedacht, damit Kunden ohne Gefrickel pip-installierbare Cores
verifizieren koennen.
Simon R. schrieb:> Martin S. schrieb:>> Mit Vivado will auch keiner arbeiten :-)> Alternative?
Vivado insbesondere IP Integrator ist das beste was es gibt!
Macht echt spass damit zu arbeiten.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten