Projekt "Open Logic Library" sammelt Geld

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

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:

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.

 Key Features:
🔹 Comprehensive library of reusable VHDL components
🔹 Configurability through VHDL generics
🔹 High-quality, well-documented code
🔹 Thorough verification: 100% code- and branch coverage
🔹 Free and open-source

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.

Bisher erstellte Funktionen/Module: 
https://github.com/open-logic/open-logic/blob/main/doc/EntityList.md

Dafür werden jetzt Unterstützer gesucht, die dem Projekt auch einen 
kleinen Obulus spenden:

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.

[Antti L. (trioflex)]

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

[Martin S. (strubi)]

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.

[Christian M. (christian_m280)]

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

[Martin S. (strubi)]

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

[Bradward B. (Firma: Starfleet) (ltjg_boimler)]

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

[J. S. (engineer)]

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.

[Martin S. (strubi)]

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.