HDL in Python / MyHDL die Zweite (unfertig)

[Martin S. (strubi)]

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!

[Weltbester FPGA-Pongo (Gast)]

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"

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

Verstehe ich das richtig: MyHDL das pendant zu z.B. Vivado HLS nur eben 
mit Python statt C als Modellierungssprache?

[Martin S. (strubi)]

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).

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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! :-)

[S. R. (svenska)]

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.

[Markus W (Gast)]

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ß.

[Tobias B. (Firma: www.elpra.de) (ttobsen)]

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.

[Lars R. (lrs)]

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.

[S. R. (svenska)]

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.

[Lars R. (lrs)]

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.

[Markus W (Gast)]

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?

[Lars R. (lrs)]

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.

[Markus W (Gast)]

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.

[Martin S. (strubi)]

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:

@hls.designrule_A
def func(M, N, O):
    result = M * N + O
    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.

[Martin S. (strubi)]

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.

[Lars R. (lrs)]

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.

[Martin S. (strubi)]

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.

[Lars R. (lrs)]

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.

[Martin S. (strubi)]

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.

[S. R. (svenska)]

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.

[Lars R. (lrs)]

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?

[Martin S. (strubi)]

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.

[Lars R. (lrs)]

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.

architecture MyIRL of top_bs is
    -- Local type declarations
    -- Signal declarations
    signal s_0f22 : unsigned(15 downto 0);
    signal clk_d36e : std_ulogic := '0';
    signal s_025e : std_ulogic;
    signal s_0edc : unsigned(15 downto 0);
    signal s_7c99 : unsigned(3 downto 0);
begin
    -- Instance barrel_shifter
    inst_barrel_shifter_0: entity work.barrel_shifter
    port map (
        clk => clk_d36e,
        ce => s_025e,
        val => s_0edc,
        s => s_7c99,
        result => s_0f22
    );
    
CLKGEN_73d5:
    clk_d36e <= not clk_d36e after 2 ns;
    
    
stim:
    process
    begin
        -- Unroll Iterator item:(57005, 8, 44288): {
            
            s_025e <= '0';
            s_7c99 <= to_unsigned(8, 4);
            s_0edc <= to_unsigned(57005, 16);
            wait until rising_edge(clk_d36e);
            s_025e <= '1';
            wait until rising_edge(clk_d36e);
            wait until rising_edge(clk_d36e);
            print("0x"& hstr(s_0f22));
            assert (s_0f22 = 44288)
                report "Failed in /tmp/ipykernel_35/1235503122.py:top_bs():36" severity failure;
            
            s_025e <= '0';
            s_7c99 <= to_unsigned(15, 4);
            s_0edc <= to_unsigned(36609, 16);
            wait until rising_edge(clk_d36e);
            s_025e <= '1';
            wait until rising_edge(clk_d36e);
            wait until rising_edge(clk_d36e);
            print("0x"& hstr(s_0f22));
            assert (s_0f22 = 32768)
                report "Failed in /tmp/ipykernel_35/1235503122.py:top_bs():36" severity failure;
        -- }
        wait;
    end process;
end architecture MyIRL;

[Lars R. (lrs)]

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.

[Martin S. (strubi)]

@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.

[Lars R. (lrs)]

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?

[Martin S. (strubi)]

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.:

a = Signal(bool())
b = a # Referenz auf a
...

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

s.next[i] = v

und generell die Stolperfallen bei solchen partiellen Zuweisungen.

>
> Wird array unterstützt?

Ja.
Zu Datentypen, siehe IRL interna (Achtung, startet den Binder) 
https://mybinder.org/v2/gh/hackfin/myhdl.v2we.git/HEAD?filepath=notebooks%2Fmyirl.ipynb

Anwendung siehe rgb2yuv.ipynb, tdpram.ipynb, ...

[Onkel Herbert (Gast)]

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.

[Lars R. (lrs)]

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.:
>

> a = Signal(bool())
> b = a # Referenz auf a
> ...
> inst = unit(b)
>

>
> 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
>

> s.next[i] = v
>

> 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

s.next = v

 schreibt, dann kann man auch

s.next[i] = v

 und

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?

[Markus W (Gast)]

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.

[Martin S. (strubi)]

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:

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.

    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.

[Lars R. (lrs)]

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.
>

>     a = [ Signal(intbv()[5:]) for _ in range(3) ]
>

>
> 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:

     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.

[Martin S. (strubi)]

@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:

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:

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.

[Lars R. (lrs)]

Martin S. schrieb:
> Wie du auf dreimal kommst, ist mir schleierhaft,

in port (bzw. die eine Richtung)
out port (bzw. die andere Richtung)
signal

[Martin S. (strubi)]

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.

[Martin S. (strubi)]

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).

[cerbi (Gast)]

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?

[vancouver (Gast)]

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

Ah sorry, mein Post bezog sich auf das ursprünglich MyHDL.

[FPGA-Experte (Gast)]

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.

[vancouver (Gast)]

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.

[Martin S. (strubi)]

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.

[Experte (Gast)]

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.

[vancouver (Gast)]

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.

[Martin S. (strubi)]

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.