Seit geraumer Zeit gibt es das OpenLogic-Projekt eines FPGA-Entwicklers
aus der Schweiz, das das Ziel hat, eine
FPGA-Vendor-unabhängige-Plattform aka Standardbibliothek zu schaffen die
man mindestens zur Überprüfung/Verifikation eigener Designs verwenden
kann.
https://github.com/open-logic/open-logic
Wobei Standardbisbliothek eher im Sinne der stdlib für C als im Sinne
von stdlogic aus dem VHDL-Bereich verstehbar ist. Also eine Sammlung von
Grundfunktionen/makros für die Verwendung in FPGA Designs. In diesem
Sinne zählt auch das AXI-Interface (Schnittstelle zwischen (ARM)-Core
und peripheral) zu den Grundfunktionen.
Die Projektbeschreibung im Original:
1
The aim of Open-Logic is to free up your time for real innovation instead of writing boilerplate code - like CDCs, FIFOs, AXI Infrastructure, RAM instantiations. Those standard elements are provided by Open-Logic out-of-the-box.
2
3
Key Features:
4
🔹 Comprehensive library of reusable VHDL components
5
🔹 Configurability through VHDL generics
6
🔹 High-quality, well-documented code
7
🔹 Thorough verification: 100% code- and branch coverage
8
🔹 Free and open-source
9
10
Open-Logic is based on the psi_common library provided by Paul Scherrer Institute but aims to enhance it in many ways - like providing transparent indicators for the quality of every piece of production code in it or adding a publicly available CI/CD flow based on VUnit and GHDL.
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.
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.
Thread beobachten
Seitenaufteilung abschalten