Hallo! Für komplexere Systeme schaue ich mich immer wieder nach brauchbaren Frameworks um und stosse des öfteren auf Ansätze, mit Python Hardware zu generieren bzw designen. Da stehen insbesondere die Module nmigen und myhdl hervor. Meine Frage ist: Was davon kann man wirklich für langfristig angelegte Entwicklung brauchen? Bei myhdl scheint es eine ganze Latte an Conversions-Problemen zu geben, bei nmigen wiederum ist viel nicht dokumentiert und es liest sich deutlich weniger gut, usw. Von myhdl lese ich, dass es in der Entwicklung kaum weitergeht und keine neuen Features dazukommen (Kann auch was gutes sein, wenn sich nichts ändert) Gibt es hier Experten, die damit regelmäßig arbeiten und dazu Tips geben können?
Markus schrieb: > Gibt es hier Experten, die damit regelmäßig arbeiten und dazu Tips geben > können? Ein Experte arbeitet nicht regelmäßig damit, ein Experte evaluiert das Ganze einmal, bewertet das zugrundeliegende Grundprinzip ("Hardware entwickeln ohne sich mit die Details von Hardware auseinanderzusetzen") und verwirft es dann als (für ihn als Experten) ungeeignet.
Markus schrieb: > Ansätze, mit Python Hardware zu generieren bzw designen. Das Problem daran ist das übliche: das verwenden dann Softwareprogrammierer, denen das Konzept von echter Parallelität in Hardware nicht geläufig ist. Und diese Softwareprogrammierer programmieren dann ihre sequentiellen Abläufe für diese Hardware so, wie sie es immer machen. Und das gibt dann halt extrem umständliche und überraschende Hardware. Oder es gibt dann halt letztlich einen Prozessorkern, auf dem das Compilat abläuft. Wenn man aber die Denkweise für das Hardwardesign drin hat, dann ist es schnurzegal, welche Sprache man für die Hardwarebeschreibung nimmt.
Markus schrieb: > Für komplexere Systeme schaue ich mich immer wieder nach brauchbaren > Frameworks um und stosse des öfteren auf Ansätze, mit Python Hardware zu > generieren bzw designen. Da stehen insbesondere die Module nmigen und > myhdl hervor. Framework? myhdl ist eher kein Framework. > Bei myhdl scheint es eine > ganze Latte an Conversions-Problemen zu geben Mir sind nur wenige bekannt. Das meiste sind Notationsfehler. Mit den Freiheitsgraden von myhdl kann man noch viel mehr "Unsinn" hinschreiben als mit VHDL. > Von > myhdl lese ich, dass es in der Entwicklung kaum weitergeht und keine > neuen Features dazukommen (Kann auch was gutes sein, wenn sich nichts > ändert) Ja, genau so ist das. > Gibt es hier Experten, die damit regelmäßig arbeiten und dazu Tips geben > können? myhdl ist hardwarenah. Der Tipp von Lothar ist gut. myhdl nimmt Dir nicht die Denkarbeit ab. Lothar M. schrieb: > Wenn man aber die Denkweise für das Hardwardesign drin hat, dann ist > es schnurzegal, welche Sprache man für die Hardwarebeschreibung nimmt. Naja. "Interfaces", jetzt ganz neu in VHDL2019, gibt es in myhdl bereits eine ganze Weile; ebenso wie vieles andere, dass es voraussichtlich niemals in VHDL geben wird. Gut, am Ende... mancherorts erzeugt man sich den VHDL-Code auch mit selbstgeschriebenem Python. Besser strukturiert, weniger Funktionsumfang. myhdl ist nichts für Softwareprogrammierer.
Lothar M. schrieb: > Und das gibt dann halt extrem umständliche und > überraschende Hardware. vereinzelt sogar sehr überraschend, vor allem überraschend viel ... > Oder es gibt dann halt letztlich einen Prozessorkern, auf dem das > Compilat abläuft. meistens kommt eine verteckte, implizit realisierte Mimik heraus, die wie ein Prozessor arbeitet und dann voreingestellte Abläufe hintackert, so ein fest codiertes Schaltwerk. Den Gipfel dieser Geschichte lieferte einst ein Physiker, der sich selber C++ beigebracht hat, die typischen Strukturen paralleler Verarbeitung in C++ und Betriebssystemen nicht kennt und dort bereits abenteuerliche Lösungen präsentiert hat und der dann die FPGAs entdeckt hat, die man ihm besser vorenthalten hätte. Die Signalverarbeitungs-pipeline, die er programmiert hat, war bei genauerem Hinsehen eine doppelt verschachtelte Hardware, die so funktionierte, wie eine Software, welche eine Hardware nachstellt. Um es in einfachen Worten zu beschreiben, würde man bei einer Logikschaltung aus einigen UND- und ODER-Gattern mit FlipFlops diese in HW einfach aufbauen und optimieren lassen. Wollte man das in C nachbilden, braucht es ein kleines Programm, dass sich die Signale vor jedem Gatter holt, die Gatterfunktion dann ausführt und die Ergebnisse zwischenspeichert, um dann das nächste Gatter anzufassen, bis alle Ergebnisse stehen und das letzte ausgerechnet werden kann. Unser Spezi hat nun eine FSM gebaut, die das komplett nachstellt, inklusive Speicher in BRAMs, Einschreibe- und Ausleseprozessen um die Ergebnisse und Inputs jedes "Gatters" (= VHDL Funktion) handhaben zu können und da in Realität statt der Gatter einiges zu rechnen war, lief das auch noch langsamer, als es ein richtiger Prozessor gemacht hätte. Im Prinizip war es wie ein in Hardware gebauter ModelSIM, der alle Prozesse nacheinander abklappert und die Funktionen virtuell im Speicher behandelt, darin eingeschlossen die binären Signale als voll belegte Realvariable. Hier haben gleich zwei Defizite zugeschlagen: Mangelnde Kenntnisse in Betriebssystemen und Methoden der Softwareentwicklung sowie mangelde Kenntnisse in digitaler Schaltungstechnik.
Lars R. schrieb: > myhdl ist hardwarenah. Der Tipp von Lothar ist gut. myhdl nimmt Dir > nicht die Denkarbeit ab. Es nimmt einem Tipparbeit ab, schränkt aber ein, denn eine ganze Reihe von Schaltungsstrukturen lassen sich da nicht gut beschreiben. Was dabei herauskommen kann, zeigt das Beispiel, dass ich eins weiter oben beschrieben habe. Die meisten dieser Programme sind darauf ausgelegt, Schaltungsabläufe ausdrücklich zu übersetzen, d.h. eine Mechanik zu entwerfen, die den Ablauf kann. Damit das allgemein funktioniert, muss zwangsläufig eine programmierbare virtuelle HW bei rauskommen, die einem Prozessor ähnelt. Die ist aber immer langsam, weil sie nur einen Schritt von mehreren abarbeiten kann, während ein angepasstes Schaltwerk mehrere Dinge gleichzeitig tun kann. Da die Abläufe und Rechenprozesse das eigentlich Aufwändige sind, macht das den größten Anteil des Ergebnisses aus. Der Rest ist ja nur reine Verschaltung, die keine Zeit frisst. Damit liefert eine automatisierte Übersetzung genau dort keine optimalen Ergebnisse, wo es am Nötigsten ist.
Weltbester FPGA-Pongo schrieb im Beitrag #6458707: > Lars R. schrieb: >> myhdl ist hardwarenah. Der Tipp von Lothar ist gut. myhdl nimmt Dir >> nicht die Denkarbeit ab. > > Es nimmt einem Tipparbeit ab, schränkt aber ein, denn eine ganze Reihe > von Schaltungsstrukturen lassen sich da nicht gut beschreiben. Beispiel?
Lothar M. schrieb: > Das Problem daran ist das übliche: das verwenden dann > Softwareprogrammierer, denen das Konzept von echter Parallelität in Damit wir uns nicht mißverstehen: Ich bin Chip-Entwickler. Mir sind die Stolperfallen bekannt. Ich will nur aus verschiedenen Gründen der Komplexität weg von Umsetzungen in Verilog (es geht um parallele Signalverarbeitung). Soweit ich verstanden habe, sind myhdl und nmigen geeignet für explizites Hardware-Design, ich möchte keine Software HLS-Ansätze betreiben. Um auf die ursprüngliche Thematik zurückzukommen, anders formuliert: Ich würde gerne prozedural DSV-Pipelines per Python generieren und die korrekte Funktion verifizieren können (und das für eine Vielzahl von konfigurierbaren Parametern). Der Prototyp läuft im FPGA. Soweit scheint das auch mit den Python-Ansätzen über Conversion nach Verilog zu gehen. Ich weiss nur noch nicht, ob ich auf nmigen oder myhdl setzen soll. Weltbester FPGA-Pongo schrieb im Beitrag #6458707: > Es nimmt einem Tipparbeit ab, schränkt aber ein, denn eine ganze Reihe > von Schaltungsstrukturen lassen sich da nicht gut beschreiben. Ich verstehe nicht ganz, was mir dein langer Text sagen soll. Was für Schaltungsstrukturen genau?
Moin, ich versuchs mal knapp: - myhdl ist schon als Framework zu sehen - es macht aus Python eine 'echte' (im Prinzip selbstverifizierende) HDL, und laesst sich elegant mit spezifischen DSP-Datentypen erweitern. Leider ist die 'Coverage' nicht ganz komplett und es gibt unschoene Einschraenkungen resp. Bugs im 'master' Tree. - Ehemaliger Hauptentwickler hat kein Interesse an Weiterentwicklung -> unzaehlige proprietaere Forks - nmigen: prozedurale Generierung von Hardware, keine klassische Analyse vorgesehen (Parsen des AST/Syntaxbaums) Markus schrieb: > Um auf die ursprüngliche Thematik zurückzukommen, anders formuliert: Ich > würde gerne prozedural DSV-Pipelines per Python generieren und die > korrekte Funktion verifizieren können (und das für eine Vielzahl von > konfigurierbaren Parametern). Der Prototyp läuft im FPGA. Soweit scheint > das auch mit den Python-Ansätzen über Conversion nach Verilog zu gehen. > Ich weiss nur noch nicht, ob ich auf nmigen oder myhdl setzen soll. Wenn du von Verilog her kommst, liest sich MyHDL besser und erscheint logisch. Aber: Pipelines kannst du nicht in dem Sinne mit der myhdl-Library generieren, nur handstricken oder eigene Frameworks draufsetzen. Faellt hier unter 'high level synthesis', dazu gibt es hier einige Threads. Grundsaetzlich sehe ich (n)migen eher als ueblen Hack, aber es gibt eine Menge freier Cores, die darauf basieren. Auf der MyHDL-Seite gibt's kaum komplexe Beispiele, das liegt wohl an der Verschlossenheit der eher industriell gepraegten User. Wenn du mit Limitierungen leben kannst: myhdl amortisiert sich trotz einiger Stolperfallen sehr schnell in der DSP-Domaene. Bei *migen ist die Wiederverwertbarkeit fragezeichenbehaftet. Ansonsten zum Thema Weiterentwicklung (hierarchieerhaltende Ausgabe/Synthese per MyHDL): Beitrag "MyHDL/Synthese per jupyosys" Einige hardwarenahe Beispiele sind da im Browser per jupyter Notebook abspulbar (Simulation sowie Synthese). Igendwann naechstes Jahr wird wohl noch eine modulare Ausgabe in VHDL dazukommen, modulo MyHDL-Maintainerpolitik.
Ich habe versucht myhdl zu benutzen, um aus einer Python-Software heraus synthetisierbare Filterblöcke zu generieren, bin aber letzten Endes gescheitert. Ich habe zwar früher Chips in VHDL und ganz früher in Verilog entworfen aber ich bin mit Syntax und dem Ökosystem von myhdl nicht zurechtgekommen und habe nach 2 Jahren frustriert das Handtuch geworfen. Für mich hat es einfach nicht gepasst, mit der Community bin ich auch nicht warm geworden. Mit migen habe ich relativ schnell erste Erfolge gehabt und versuche jetzt auf nMigen umzusteigen, ich komme mit dem Ansatz besser klar, aber momentan fehlt mir die Zeit. Mir gefällt jedenfalls der Ansatz, mit Python Fixpointblöcke komfortabel testen und analysieren (im Zeit- und Frequenzbereich!) und dann auch als HDL exportieren zu können. Als Proof-of-Concept habe ich FIR-Filter erzeugt mit optionaler Sättigung und Trunc/Round/Fix Quantisierung. Ich würde gerne als nächstes ein paar einfache IIR-Filter generieren, hoffentlich habe ich Anfang nächsten Jahres wieder mehr Zeit. Ein Nachteil von (n)Migen ist übrigens der fehlende VHLD-Export (falls Du das brauchst). Wenn Du Interesse hast, können wir uns ja mal kurzschließen.
Christian M. schrieb: > Ich habe versucht myhdl zu benutzen, um aus einer Python-Software heraus > synthetisierbare Filterblöcke zu generieren, Willkommen im Forum! pyfda wurde hier schon ein paar mal weiterempfohlen. Danke dafür.
Ich kenne nur MyHDL und der Hauptvorteil ist, daß man mit einer modernen Programmiersprache (Python) arbeiten kann. Das ermöglicht die Verwendung von entsprechenden Entwicklungstools und (noch wichtiger) Bibliotheken. Die Syntax ist etwas kompakter als VHDL, so daß man sich auch etwas Tipparbeit spart. Es gibt einen eingebauten Simulator, was gegenüber VHDL und Verilog auch ein großer Vorteil ist. Das größte Problem was für mich immer, daß man keine VHDL/Verilog IPs mitsimulieren kann. Da fast jedes Design heutzutage solche IPs benutzt, ist das für die Entwicklung auf Top-Level Ebene für mich ein KO Kriterium; aber für die Entwicklung von reinen RTL-Subkomponenten durchaus zu gebrauchen. Ein weiterer Nachteil war, daß man keine parametrierbare Komponenten (mit Generics) generieren kann. Hier ein Link zu meinem MyHDL-Vortrag auf dem FPGA Kongress 2014, falls du ihn noch nicht kennst: https://www.slideshare.net/GuyEschemann/2014-all-programmabe-days-fpga-design-with-python Wenn es um die Entwicklung von DSP-Blöcken geht ist HLS (High-Level Synthese) meiner Meinung nach das Werkzeug der Wahl. Die Eingabesprache ist zwar kein Python, sondern C oder C++, aber diese Werkzeuge können sehr effizient und flexibel sequenziellen Code nach RTL (VHDL oder Verilog) kompilieren.
Guy Eschemann schrieb: > Das größte Problem was für mich immer, daß man keine VHDL/Verilog IPs > mitsimulieren kann Es gibt ein CoSimulations-Objekt, was nach aussen wie ein HDL Block fungiert, und via Pipe mit einem V*-Simulator per VPI spricht. Das ist nicht wahnsinns schnell, aber reicht meist. VPI hat halt Limitierungen. Ansonsten gibts noch andere Moeglichkeiten per GHDL ueber das (abgespeckte) VHPI-Interface, da kann man mit shared Memory (schnell) oder ueber Netzwerk (verteilte co-Simulation) arbeiten. Guy Eschemann schrieb: > Wenn es um die Entwicklung von DSP-Blöcken geht ist HLS (High-Level > Synthese) meiner Meinung nach das Werkzeug der Wahl. Die Eingabesprache > ist zwar kein Python, sondern C oder C++, aber diese Werkzeuge können > sehr effizient und flexibel sequenziellen Code nach RTL (VHDL oder > Verilog) kompilieren. HLS geht auch wunderbar per Python (IMHO viel maechtiger als per C++-Ansatz). Filterdesign mit genau den Bitbreiten, die man benoetigt (modulo Fehlerbits) gehen da natuerlich wie gehabt mit den klassischen Octave/Matlab-Designhilfen. Seit yosys muss man auch den fehleranfaelligen Weg (Verifikation) ueber pre-synthesis-Konversion in V*-Sprachen nicht mehr gehen. Ist aber nicht Teil von MyHDL und wird es wohl auch nicht mehr werden.
Martin S. schrieb: > Seit yosys muss man auch den fehleranfaelligen Weg (Verifikation) ueber > pre-synthesis-Konversion in V*-Sprachen nicht mehr gehen. > Ist aber nicht Teil von MyHDL und wird es wohl auch nicht mehr werden. Für mich (und vermutlich auch für andere) ist der Weg über V* kein Nachteil sondern ein Vorteil. Spontan verstehe ich auch nicht, wo der Nachteil liegen soll. Wenn es funktioniert, dann brauchst das V* ja nicht angucken. Wenn irgend kleiner Fehler im Tool drin ist, dann suchst Du Dich kaputt, wenn es von Python direkt in die Netzliste geht.
Lars R. schrieb: > Spontan verstehe ich auch nicht, wo der Nachteil liegen soll. Wenn es > funktioniert, dann brauchst das V* ja nicht angucken. Wenn du MAC (multiply-accumulate) z.B. mit sign-extension implementierst, stoesst du bei einer Latte von Umsetzungen via V*-transfer auf Bugs in der Synthesesoftware. iverilog rechnet's dann z.B. richtig, aber die FPGA-HW macht was anderes. Dasselbe auch auf der VHDL-Seite, da waere eigentlich alles sehr streng definiert (keine impliziten Konversionen wie bei Verilog), nutzt aber nix, wenn Hersteller den Standard verstuemmeln/ignorieren. Dazu kommt leider, dass upstream-myhdl diesen Typ fehlerhafter Umsetzung bei der VHDL-Ausgabe seit Jahren ungefixt laesst. Naechster Punkt ist, dass die Synthese aus dem funktionalen V*-Source 'erraten' muss, was sie instanzieren soll. Einfacher ist es, ein Konstrukt direkt in eine Blackbox (Primitive) zu uebersetzen, welche bereits verifiziert ist. Das ist zwar in diesem Zwischenschritt nicht portabel a la V*, aber gibt bereits auf der HLS-Ebene eine optimale Kontrolle darueber, was instanziert werden soll. Der Source bleibt dabei derselbe, nur die 'design rules' aendern sich per FPGA-Architektur. Der Debugging-Overhead haelt sich dank divide-et-impera und den Moeglichkeiten zur laufenden Verifikation ziemlich in Grenzen. Meistens sieht man sofort in der post-syn-verifikation (Co-Simulation der funktionalen Beschreibung gegen synthetisierte Fassung) was schieflaeuft.
Martin S. schrieb: > Lars R. schrieb: >> Spontan verstehe ich auch nicht, wo der Nachteil liegen soll. Wenn es >> funktioniert, dann brauchst das V* ja nicht angucken. > > Wenn du MAC (multiply-accumulate) z.B. mit sign-extension > implementierst, stoesst du bei einer Latte von Umsetzungen via > V*-transfer auf Bugs in der Synthesesoftware. iverilog rechnet's dann > z.B. richtig, aber die FPGA-HW macht was anderes. Dasselbe auch auf der > VHDL-Seite, da waere eigentlich alles sehr streng definiert (keine > impliziten Konversionen wie bei Verilog), nutzt aber nix, wenn > Hersteller den Standard verstuemmeln/ignorieren. Für das nächste, im Moment noch unbekannte Problem: Wie schnell gelange ich zu der Erkenntnis, ob der Fehler in Python-to-Netlist, im Simulator oder in den Hersteller-Libaries liegt? Und wenn der Fehler beim Hersteller liegt, wie komme ich zu einem Workaround? Manuelles Nachoptimieren der V*-Verhaltensbeschreibung fällt bei Deinem Ansatz schon einmal weg. Es gibt auch genug Sachen, die gehen in V* aber in Myhdl nicht; vielleicht auch nicht mit Deinem Ansatz. Bisher mit Myhdl kein Problem, das kann man im V*-Code anpassen. Falls aber nur noch Netzlisten-Code heraus kommst, wird es unschön; sowohl bzgl. Einbinden aus auch bzgl. Simulation. > Naechster Punkt ist, dass die Synthese aus dem funktionalen V*-Source > 'erraten' muss, was sie instanzieren soll. Dafür ist sie da. > Der Source bleibt dabei derselbe, nur die 'design rules' aendern sich > per FPGA-Architektur. Der Debugging-Overhead haelt sich dank > divide-et-impera und den Moeglichkeiten zur laufenden Verifikation > ziemlich in Grenzen. Es gibt auch noch Fehler in der physikalischen Hardware. Mit der kompletten Netzliste allein ist es mitunter schwierig mit dem Support. Weiterhin: In der aktuellen Situation sind opensource-Synthese-tools bei den Herstellern noch nicht so etabliert/akzeptiert, wie bei der Software der gcc. Was ist mit Hardwarefehlern, die versehentlich mit dem Herstellersynthese-Tool nicht zum Fehler im Design führen aber mit Python-to-Netlist schon? Was ist mit undokumentierten Hardwarefehlern, die das Herstellersynthese-Tool absichtlich umschifft? Bei gcc hat man erkannt, dass es mit llvm mitunter besser geht. Warum sollten wir bei der HW die Uhr wieder zurück drehen? Wenn die V*-Verhaltensbeschreibung als Input für das Herstellertool nicht das Soll-Ergebnis liefert, dann kann gehe ich damit zum Hersteller oder ins Support-Forum. Mit einer Netzliste von extern geht das im Moment nicht oder nicht so gut. Die Frage ist natürlich, was man möchte. Möchte man sich selbst ein All-in-One-Übersetzer-Tool bauen oder möchte man FPGA-Designs bauen. Bei mir ist es letzteres. Nicht zuletzt im eigenen Interesse helfe ich gern beim pin-down des Problems, jedoch benötige ich für jedes Problem einen Lösungsansatz, der in endlicher Zeit zum Ziel führt. Letztlich ist alles schon da gewesen (fehlerhaft Lib, Sim, Synthesetool, Hardware) > Meistens sieht man sofort in der > post-syn-verifikation (Co-Simulation der funktionalen Beschreibung gegen > synthetisierte Fassung) was schieflaeuft. Wenn das bei Dir effizient funktioniert, Hut ab. Ich kann zwar sofort sehen, dass etwas schief läuft, aber ich sehe nicht sofort, was bei einer Netlist schief läuft. Für Übersetzungen von Highlevel* zu Verhaltensbeschreibung-V*-Code kann ich das jedoch sehr wohl noch effizient (zB. Myhdl und Matlab). Last but not least: Vertrauen in die Zuverlässigkeit. Myhdl und andere Python-basierte Ansätze werden bereits wenig genutzt. Der von Dir vorangetriebene Ansatz noch weniger. Das ist ein großes Minus beim Vertrauen in ein scheinbar funktionierendes, damit erzeugtes Design. Es hat Gründe, warum nicht plötzlich überall der chinesische FPGA mit zugehörigem Synthese-Tool benutzt wird. Ein wesentlicher davon ist die größe der bekannten Nutzerbasis. Für die opensource-Synthese-Ansätze (yosys) hoffe ich das Beste. Die Nutzerbasis könnte da groß genug werden. Weniger optimistisch bin ich bzgl. Tools, wo eins von Python zu Netzliste übersetzt, das nächste von Perl und das nächste von Java, usw. Die Nutzerbasis ist ja schon bei Python-zu-V*-Verhaltensbeschreibung relativ klein. Ich vermute nicht, dass eine "Anflanschung" an yosys oder ähnlich zum erhofften Ziel führt. Im Moment kann der Anwender jederzeit in die V*-Verhaltensbeschreibung schauen und jederzeit auf das Fallback "Herstellertool" gehen. Das hat man dann alles nicht mehr. Bei einem Problem steht man dann da und hat als Ansprechpartner praktisch nur Dich (und ggf. eine Handvoll weitere Personen, falls es mal dazu kommt). Bei der Simulation besteht die Problematik mit dem Vertrauen ebenfalls. Das besteht im Moment bei Myhdl auch, aber da hat man ja auch noch die V*-Verhaltensbeschreibung. Bei Deinem Ansatz dann nur noch die Netzliste. Dann Verifikationstools bzgl. des Desings (also der vom Nutzer geschriebene Code), dh. asserts, code coverage bis zu formale Verifikation. Und seien es auch nur die (neuesten) Opensource-Tools dafür. Das ist nicht möglich mit Deinem Ansatz, soweit ich es überblicke (oder baust Du das auch noch, quasi allein). Mit Myhdl geht da noch was. Dort gibt es zwar Einschränkungen, die jedoch aus einem Konzept heraus entstehen, das an anderen Stellen wiederum wesentliche Vorteile hat. Es doch nicht so, dass die Welt immer noch Verilog und VHDL benutzt, nur weil noch nie jemand eine bessere Idee hatte. Wir sind konservativer als die Embedded-Softwerker mit C, und das nicht ohne technisch-mathematischen Grund. Natürlich gibt es die Highlevel-Ansätze für alles und jeden, sowohl bei SW, als auch bei HW. Aber das ist dann nicht das Replacement für MyHdl. Bisher war mein Verständnis, dass Dein Ansatz auch nicht in Richtung HLS geht.
@Lars: Ich weiss nicht genau, worauf du hinauswillst. Mein Eindruck ist, du verrennst dich da etwas. Ich halt's mal kuerzer: Generell gilt: Irgend einem Tool als 'working reference' musst du vertrauen. Darauf aufbauend ergibt sich die "Zuverlaessigkeit" der Verifikationskette. Ob sich das fuer dich jeweils amortisiert, musst du selber evaluieren, hier gelten OpenSource-Prinzipien (kein Support, read the source). Die Community, die Python-Ansaetze verfolgt, mag klein sein, wie du suggerierst. Spielt aber nicht wahnsinns Rolle, der V*-Mainstream interessiert marginal, es geht mir insbesondere um nachhaltige, gut wartbare IP-Cores, nicht, Tools zu 'verkaufen' (siehe OpenSource). V* kann man nach wie vor ausgeben und einbinden (betr. Thema Workarounds zu Tools/HW-Bugs, falls noetig). Ich weiss nun nicht, von welchem Ansatz du redest, mit dem das dann nicht mehr gehen sollte. Die erwaehnte 'Netzliste' ist im yosys-Fall die interne RTL-Representation (RTLIL). Die kannst du auch modular in Verilog ausgeben und durch die Verifikation spulen. Was die erwaehnte HLS-Schiene insbesondere angeht: in-house-Tool, nicht Teil von MyHDL, setzt nur partiell darauf auf, Pipelines lassen sich auch in MyHDL-@blocks ausgeben. Der Rest der Verifikationskette bleibt gleich. Das Einkreisen der Fehler ist per Co-Simulation/Verifikation wenig dramatisch. Gibt's ein paar Beispiele zu im jupyosys-Hackerspace. Grundsaetzlich unterscheidet sich obiger Ansatz nur von 'upstream', dass die Hierarchie beibehalten wird, und eine Blackbox-API dazukommt. Der Rest ist Interfacing zur entsprechenden RTL-Ausgabe (yosys). Damit hat man mehr Kontrolle ueber die 'Inference' (Umsetzung einer funktionalen Beschreibung). Synthetisierbaren Code schreiben lernen wie in der V*-Welt muss man aber nach wie vor.
Martin S. schrieb: > @Lars: Ich weiss nicht genau, worauf du hinauswillst. Wie ich bereits geschrieben hatte: Die V*_Verhaltens_Beschreibung wird von vielen Anwendern benötigt. Dafür hatte ich diverse Gründe angegeben. Martin S. schrieb: > Die Community, die Python-Ansaetze verfolgt, mag klein sein, wie du > suggerierst. Spielt aber nicht wahnsinns Rolle, der V*-Mainstream > interessiert marginal, es geht mir insbesondere um nachhaltige, gut > wartbare IP-Cores, nicht, Tools zu 'verkaufen' (siehe OpenSource). In vielen anderen Fällen muss Code gereviewt werden und ggf. auch verifiziert werden. Mit Verifikation meinte ich nicht das Tool sondern die Verhaltensbeschreibung. Verifikations-Tools, die auf MyHDL laufen, sind mir nicht bekannt. Auch Opensource-Tools laufen nur auf V*. Martin S. schrieb: > Generell gilt: Irgend einem Tool als 'working reference' musst du > vertrauen. > [...] > Ob sich das fuer dich jeweils amortisiert, musst du selber evaluieren, > hier gelten OpenSource-Prinzipien (kein Support, read the source). Richtig. Dabei geht es nicht so sehr darum, ob es opensource ist und ob es etwas kostet oder nicht. Ein Tool, das die Netzliste erzeugt, erfordert viel mehr Vertrauen als ein Tool, das nur eine Verhaltensbeschreibung erzeugt. Die Fragen sind: . Wer hat es entwickelt? Wie viele Personen? Welche Firma? Opensource ist ok, aber eine Einmann-show mit 0-5 Anwendern und auch noch direkt auf die Netzliste ist schwierig. (Das ist auch der Grund, warum es mit myHDL ein Stück weit funktioniert hat. Die Schritte, die myHDL macht, sind händisch nachvollziehbar. Fehler sind schnell gefunden und eingegrenzt) . Wie viele Personen benutzen es und haben es bereits benutzt? . Wer könnte (ggf. gegen Bezahlung) Support bieten? . Beeinflusst die Benutzung des Tools das Fehlerfinden oder den Support in nachfolgenden Schritten und falls ja wie stark? Von ganz einfachen Dingen wie dem Benutzen der Xilinx ILA bis hin zum Finden von Hardwarefehlern im FPGA-Silicon oder auf dem PCB. Das sieht meiner Ansicht nach eben nicht ganz gut aus, wenn man Stand heute prinzipiell von Python direkt auf die Netzliste geht, bzw. gehen muss. Es sieht eher so aus, dass es bzgl. der angesprochenen Themen das Leben erschwert. Die Daseinsberechtigung von Deinem Ansatz will ich keinesfalls in Frage stellen. Grund meiner Argumentation ist, dass ich (noch) nicht nachvollziehen kann, warum es jemand anders als Du selbst benutzen sollte. Dein Ansatz mag Fehler nicht haben, die myhdl hat, und er mag mehr Features haben, die myhdl hat. Aber das nützt nur bedingt, wenn es mich dafür an anderer Stelle ein Vielfaches der Zeit kostet oder kosten kann.
:
Bearbeitet durch User
Lars R. schrieb: > Ein Tool, das die Netzliste erzeugt, erfordert viel mehr Vertrauen als > ein Tool, das nur eine Verhaltensbeschreibung erzeugt. Dazu musst du in diesem Fall yosys vertrauen. Nochmal: Python erzeugt die noch abstrakte RTLIL 'intermediate representation', keine Netzliste. Ansonsten musst du das oben aufgelistete einfach selbst verifizieren. An einer Stelle in der V*-Kette musst du bei manchen Marken auch einer closed-Source-Synthese vertrauen. Ich habe hier fuer VHDL ca. 20 Testcases, wo bei Lattice/Xilinx die unterschiedlichsten Sachen bei rauskommen... Lars R. schrieb: > Die Fragen sind: > ... Solche 'Marktforschungs'-Fragen zu beantworten habe ich mir eigentlich abgewoehnt. Ich kann dazu allerdings sagen: - Nutze github - Die meisten Forks von MyHDL sind Einmann-Shows, wie GHDL - Die Wahrscheinlichkeit, dass Firmen aufgekauft werden, ist hoeher, als dass Einmann-OpenSource von github getilgt wird - Wenn konkret ein Bug auftaucht, wird er typischerweise gefixt Was die Fehlersuche in Bezug auf HW angeht: Da wird es sehr FPGA-spezifisch. Ich habe bisher nur ECP5 in der aktiven Anwendung unter yosys und kann auch nur da Support bieten. Lars R. schrieb: > Aber das nützt nur bedingt, wenn es mich > dafür an anderer Stelle ein Vielfaches der Zeit kostet oder kosten kann. Genau deswegen muss sich ein OpenSource-Tool/dessen Erweiterung auch fuer mich im Projekt amortisieren. Sonst haette ich damit gar nicht erst angefangen. Duerfte so ziemlich offensichtlich sein :-) Wie sich die Bilanz im Einzelnen auswirkt, muss jeder fuer sein Projekt selber rausfinden. Was geht und was nicht geht, ist IMHO erst mal ausreichend dokumentiert. Lars R. schrieb: > Dein Ansatz mag Fehler nicht haben, die myhdl hat, und er mag mehr > Features haben, die myhdl hat Lies doch nochmal oben durch, was ich geschrieben habe. Auch zwischen HLS und RTLIL liegt die gleiche myhdl-kompatible Struktur. Du kannst also nach wie vor V* nach Lust und Laune ausgeben und mit was auch immer verifizieren, oder gegen die RTLIL-Variante gegenchecken. *migen dito. Allerdings: das grundsaetzliche bereits oefters angesprochene Problem bei MyHDL ist halt, dass viele Python'sche Konstrukte nicht synthetisierbar sind und es da bereits Diskrepanzen zwischen den verschiedenen Backends gibt. Mit der Baustelle wird man eine Weile leben muessen. Und da geht definitiv am meisten Zeit bei drauf. Bei *migen ist das (noch) simpler. Python kann grundsaetzlich Selbst-Verifikation per AST-Analyse (wie es MyHDL macht), somit kann man per Spezifikation von Designregeln schon fruehzeitig meckern: Synthetisiert so nicht fuer Target/Tool X/Y.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.