Projekt "Open Logic Library" sammelt Geld

https://www.gofundme.com/f/dedicated-github-runner-for-open-logic-fpga-standard-library

IMHO auch eine Gelegenheit über die Möglichkeiten einer solchen FPGA-Entwicklungsmethodik zu diskutieren.

OLO basiert auf psi_common von PSI. https://github.com/paulscherrerinstitute/psi_common

Author hat PSI verlassen und will jetzt mit den "verbesserten" code von PSI geld verdienen. Naja vielleicht ist der OLO auch soviel besser als psi code.

Ich enhalte mich mal weiterer negativer Kommentare zum leider in der Schweiz recht verbreiteten Coding-Style. Zwei Punkte vielleicht:

1. der Wiederverwertbarkeitswert solcher Library-Ansaetze (es ist nicht der erste) ist relativ gering, wenn z.B. beim Kunden X das Dogma 'std_ulogic im Interface' und 'keine exzessive Nutzung von Variablen' gilt. Vielleicht sollte man mal langsam auf eine modernere HDL-Methodik setzen.
2. Die Projektfamilie haette gut daran getan, wenigstens fuer die VHDL-Puristen eine naehere Anbindung an OSVVM zu schaffen. Ansonsten sehe ich nicht viel state-of-the art, ueber VUnit laesst sich jetzt streiten.

Der Umfang scheint nach wie vor immer noch mager im Vergleich zu libhwt und Konsorten. Somit erschliesst sich mir nicht so recht, warum man 'yet another' sponsoren sollte, wenn es das PSI nicht tut.

Martin S. schrieb:

Schweiz recht verbreiteten Coding-Style

Würde mich dennoch näher interessieren! Und meinst Du speziell VHDL oder allgemein Coden?

Gruss Chregu

Ich meine in dem Kontext den VHDL-Coding-Style, der sich an einigen Schweizer HS fossiliert hat.

Ich meine in dem Kontext den VHDL-Coding-Style, der sich an einigen Schweizer HS fossiliert hat.

Wie ich kürzlich gelernt habe, war es schon mal ein Schweizer, der bezüglich des Codierstils ein tiefe Kontroverse anzettelte.

Die Formulierung "GOTO statement considered harmful" stammt wohl in diesem polarisiwrenden Wortlaut nicht von Holländer Dijskstra, sondern aus der Feder des Schweizer Niklaus Wirth, der den von Edsger original eingereichten Untertitel "A Case against the GOTO-Statement" für die Konferenz verbal verschärfte. (Anhang, handschriftliche Notiz rechts)

In der Vergangenheit hat sich schon oft gezeigt, das Projekte, die sich schon am Editierstil und "butterweichen" Style-Guidelines entzweien, zum Scheitern verdammt sind. Hier soll es doch eher um formale Korrektheit und nicht individuelle Schönheit gehen. Architekturunabhängi resp. einfach portabel wäre auch wünschenswert.

Bradward B. schrieb:

In diesem Sinne zählt auch das AXI-Interface (Schnittstelle zwischen (ARM)-Core und peripheral) zu den Grundfunktionen.

Da gäbe es viel zu verifizieren. Das AXI - besonders da vom X ist so lückenhaft, wie der Käse aus dem Land des o.g. Entwicklers.

Ich schmeiße AXI soweit es geht aus den Projekten raus und empfehle das auch meinen Kunden.

Was die LIB angeht:

Bradward B. schrieb:

innovation instead of writing boilerplate code - like CDCs, FIFOs, AXI Infrastructure, RAM instantiations.

All diese Sachen sind bei vielen Entwicklern bereits als fertiger nativer Code vorhanden, samt Testbenches. Das sind auch keine großen Zeitfresse, die zu instanziieren. Es geht regelmäßig um den Beschreibungsaufwand der Tests, angefangen vom Text in den Dokumenten, den formalen und technischen requirements und schließlich dem Code. Da kann man je nach Ebene mit VHDL sehr schnell lolevel Zugriffe applizieren und das Modul absichern.

So richtig anspruchsvoll ist das eh nur bei komplizierten Interfaces wie SERDES und Transceiver-Designs, Video-Cores etc. Oftmals kommt eine Testbench da schon von einem Core. Hat man das, nimmt man das aus der Chain und modelliert des Rest funktional.

Dafür wiederum eignet sich in der Tat für manche Zwecke VUNIT, wobei der Beschreibungsaufwand auf unterer Ebene eher steigt, als sich verringert und nur da wirklich wirkt, wo C-ähnlich gearbeitet wird und oben auch ein Prozessor sitzt, der da ähnlich funktioniell zugreift.

Dann bliebe noch OSVVM, das schon länger exsitiert, aber uach nur zögerlich angenommen und eingesetzt wird. Ich habe das vor 3 Jahren mal eingesetz und evaluiert und dabei den progress angeschaut: Viel hat sich da seither nicht getan.

Beim Dave 'down under' gibt es zu den Frameworks auch etwas Senf: https://www.eevblog.com/forum/fpga/vunit-uvvm-osvvm-what-are-similarities-and-differences/msg5491540/#msg5491540

Mein bitterer Fazit: Das kommt alles Jahre zu spät. Im Rahmen einer Infrastrukturplanung fuer eine Startup-Entwicklung, die sich auf VHDL festlegen moechte, kann man sich schon mal Gedanken dazu machen. Als Verifikationsframework auf VHDL-Ebene ist OSVVM definitiv gut durchdacht und interagiert auch relativ geschmeidig mit OpenSource-Tools. Aber fuer Einzelkaempfer schon ein gehoeriger Overhead. Und dann kommt ein Kunde mit einem Verilog-Modul und moechte es co-verifiziert haben.

Schlussendlich naehert man sich dem VHDL-Limes des Machbaren halt in immer kleineren Schritten, und das eigentlich "eingebaute" Problem der VHDL-Verifikation sorgt fuer immer neue Baustellen, Tools und yet another library. Deswegen: Wozu? Die Tendenz geht in Richtung Verschmelzung HW/SW und automatisierte Selbstverifikation, wo die V*HDL grundsaetzlich versagen.

Ich bin der Maintainer und Haupt-Author von Open Logic. Da ich kürzlich über diesen Thread gestolpert bin erlaube ich mir ein kurzes Statement zu ein paar Aussagen abzugeben.

1. Das referenzierte Crowdfunding ist inzwischen abgeschlossen und die damit finanzierte Build Runner Infrastruktur steht. Trotzdem bin ich weiter froh um Spenden um das Projekt weiterführen zu können, am einfachsten kann man das Projekt über "GitHub Sponsors" (siehe Readme im Repo) unterstützen.

2. Antti L. schrieb:

https://www.gofundme.com/f/dedicated-github-runner-for-open-logic-fpga-standard-library

IMHO auch eine Gelegenheit über die Möglichkeiten einer solchen FPGA-Entwicklungsmethodik zu diskutieren.

OLO basiert auf psi_common von PSI. https://github.com/paulscherrerinstitute/psi_common

Author hat PSI verlassen und will jetzt mit den "verbesserten" code von PSI geld verdienen. Naja vielleicht ist der OLO auch soviel besser als psi code.

Die Unterstellung, dass ich mich aufgrund bestehenden Codes bereichern möchte weise ich ganz klar zurück.

Ich habe mehrere hundert Stunden Aufwand in das Open Logic Projekt hineingesteckt und wenn ich alle Spenden und Arbeitsstunden zusammenzähle maximal einen einstelligen Stundenlohn in Euro. Wenn die Motivation finanzieller Natur wäre, hätte ich die Zeit besser in meinen Hauptberuf investiert. Aktive Nutzer um eine Spende zu bitten ist aus meiner Sicht legitim und das werde ich auch weiter tun.

Das Projekt zielt darauf ab der FPGA Community die vertrauenswürdige Standard Bibliothek zur verfügung zu stellen, die ich immer selbst vermisst habe. Jeder ist frei Open Logic einzusetzen oder nicht - und von Entwicklern die es nicht einsetzen erwarte ich auch keine Spenden.

Ich habe auch nach meinem Weggang beim PSI contributions zu den PSI libraries gemacht. Den Entscheid Open Logic zu gründen habe ich gefällt, als ich entschieden habe die Library signifikant zu erweitern und zu überarbeiten. Dafür wollte ich freie Hand haben und mich nicht für jeden Schritt mit dem PSI absprechen. Und ja, Open Logic hat zu signifikanten veränderungen geführt, sowohl am Production Code selbst als auch an Test-Benches und der gesamten Infrastuktur.

3. Coding Style

Ich bin mir bewusst, dass man es in Sachen Coding Style nie allen recht machen kann. Ich habe einen Style gesetzt und prüfe diesen auch mit dem Linter um Open Logic wartbar zu halten. Das heisst aber nicht, dass ich glaube dass das "der einzig richtige Stil" ist - so etwas gibt es meines erachtens nicht und jeder Nutzer soll seiner eigenen Guideline folgen.

Aus meiner Sicht sollte der interne Style für die Nutzung von Open Logic auch keine Rolle spielen. Wenn man Linux compiliert und nutzt bedeutetd das ja auch nicht das der betreffende Quellcode dem eigenen Stil entsprechen muss - das selbe gilt aus meiner Sicht generell für in einem Projekt eingesetzten 3rd Party Code.

4. OSVVM vs. VUnit

Ich habe mich für VUnit entschieden da ich damit Erfahrung habe und effizient bin. Ich sehe aktuell auch keine signifikanten Probleme damit, würde heute OSVVM aber in Betracht ziehen. Trotzdem glaube ich, dass ich aktuell mehr Wert generieren kann wenn ich die Zeit in neue Features investiere als in die Umstellung des Verifikationsframeworks.

Wenn jemand zum Projekt beitragen möchte und die Umstellung auf OSVVM implementieren möchte, bin ich sehr offen dafür das zu diskutieren.

Oliver B. schrieb:

Ich habe mehrere hundert Stunden Aufwand in das Open Logic Projekt hineingesteckt und wenn ich alle Spenden und Arbeitsstunden zusammenzähle maximal einen einstelligen Stundenlohn in Euro. Wenn die Motivation finanzieller Natur wäre, hätte ich die Zeit besser in meinen Hauptberuf investiert. Aktive Nutzer um eine Spende zu bitten ist aus meiner Sicht legitim und das werde ich auch weiter tun.

Danke dafür.