Versionsverwaltung in der FPGA-Entwicklung: git is shit, svn not (auch wenn Linus das anders sieht)

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

Auf dem FPGA Developer Forum in Genf findet sich ein Poster, das sich 
mit der Eignung verschiedener Code-Verwaltungssysteme in der 
FPGA-Entwicklung auseinandersetzte.

Der wohl aus leidvoller und langjähriger Erfahrung geschriebene Beitrag 
fokusierte auf die im Vergleich zu Software-Apps Entwicklung lange 
Compilezeiten (Vitis 2h-4h) und Größe wie Anzahl der erzeugten Artefakte 
(binary, Peta-Linux-Image), richtet sich also eher an größere Projekte 
mit SoC-FPGA's.

* 
https://indico.cern.ch/event/1549296/contributions/7012275/attachments/3278140/5859467/SVN_vs_GIT_FDF26_Poster_final2.pdf 
(Fazit siehe Anhang)

Wie in git ist die Eignung für die Arbeit in Teams Hauptaugenmerk bei 
der Entwicklung, möglicherweise liegt in der unterschiedlichen 
Team-Struktur die Ursache für die Besonderheiten im Source-Gebrauch.

Der Autor geht davon aus, das es im FPGA-Bereich nicht sinnvoll ist, im 
Alltag benötigte Compilate aus den versionierten HDL-Quellen zu 
erzeugen, sondern diese (oft Binaries) genannten Artifakte müssen (in 
der FPGA-Entwicklung) mit im Depot abgelegt werden. Das macht aus einer 
Quell-Code-Verwaltung eine File-Verwaltung, die auch reports, logs etc. 
einbezieht.

Im Poster wird insbesonders auf den Unterschied zwischen der 
Release-Generierung (merging) von getagten Source-files gegenüber dem 
pull-request von branches (mit automatischen merge) eingangen.

Historischer threads zum Thema git oder svn:
* Beitrag "SVN oder GIT"
* Beitrag "FPGA Entwicklung und SVN"
* Beitrag "Git for hardware"

[Gustl B. (gustl_b)]

Bradward B. schrieb:
> Der Autor geht davon aus, das es im FPGA-Bereich nicht sinnvoll ist, im
> Alltag benötigte Compilate aus den versionierten HDL-Quellen zu
> erzeugen, sondern diese (oft Binaries) genannten Artifakte müssen (in
> der FPGA-Entwicklung) mit im Depot abgelegt werden.

Was ist das denn für ein Satz?! In der Mitte steht ein "sondern" aber 
das davor hat nichts mit dem danach zu tun.

Warum ist das vor dem "sondern" nicht sinnvoll?

Das nach dem "sondern" ist genau keine Lösung oder Ersatz für das vor 
dem "sondern".
Was spricht denn dagegen einfach Beides zu tun? Also die Kompilate aus 
versionierten Quellen zu bauen und dann das Ergebnis an einem anderen 
Ort abzulegen? Oder nur den Bitstream ins Repo zu legen aber den 
Designcheckpoint und die ILA und die Logs auf ein Netzlaufwerk zu 
kopieren.

Jedenfalls funktioniert das wunderprächtig mit Git.

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

zu "Erzeugte Daten auch in die Versionsverwaltung ?!":

Für den Autor des Posters ist der Bedarf an Festplattenplatz beim User 
wohl der Hauptgrund, dem Umgang mit erzeugbaren files besondere 
Aufmerksamkeit zukommen zu lassen (siehe den Posterausschnitt mit 
Hervorhebungen im Anhang).
Er spricht von "unusable sizes" die wiederholt bei git repos auftraten 
und das bei den Nutzer-Maschinen, nicht bei dem zentralen Server. Der 
Autor bringt das im Zusammenhang mit der bei git nicht unüblichen 
Arbeitsweise immer das gesamte Depot auch auf den Nutzermaschinen zu 
halten. Im zweiten Teil des Auszuges werden Vorschläge genannt, wie man 
unter git dieses Problem abschwächen kann: 'flache Clone' ("shallow 
clone (--depth)" und "Large file storage LFS" bei git.

In dem Poster selbt wird nicht auf weitere Begründungen eingegangen, die 
man daneben in diesen Zusammenhang hört, das es eben aus Gründen des 
Konsistenz-erhalts und der Vermeidung von Redundanzen es "sinnvoll" ist, 
nur die Quell-Dateien abzulegen und keine Produkte aus dem Built-prozess 
..
das sei eben (ausschliesslich) eine Code-Verwaltung für die Entwicklung 
und kein Fileserver fürs Deployment/Firmwareupdate in der 
Geräteproduktion/Service.

Der Poster-Autor zieht in diesem Zusammenhang auch die lange Laufzeit 
des built-prozesses beim FPGA heran (zwei bis vier Stunden), der es 
nötig mache, auch Ergebnisses des built-prozesses mit in der 
Source-Verwaltung abzulegen. Vivado in FPGA-builtprozeß erzeugt auch 
recht große "Zwischen-dateien", beispielsweise Design check points 
(*.dcp).

[Ein T. (ein_typ)]

Gustl B. schrieb:
> Bradward B. schrieb:
>> Der Autor geht davon aus, das es im FPGA-Bereich nicht sinnvoll ist, im
>> Alltag benötigte Compilate aus den versionierten HDL-Quellen zu
>> erzeugen, sondern diese (oft Binaries) genannten Artifakte müssen (in
>> der FPGA-Entwicklung) mit im Depot abgelegt werden.
>
> Was ist das denn für ein Satz?!

Unser... "Freund" hat gewisse kommunikative Handicaps. Das beginnt mit 
seiner mangelhaften Beherrschung der eigenen Muttersprache, geht über 
seine häufige Verwechslung von Deutlichkeit mit Unhöflichkeit und endet 
nicht damit, daß er einfach nicht richtig zitieren will. Denn neben, 
nein, trotz seiner Schwächen ist er ein richtiger kleiner Held, der 
immer nur hilft und Gutes tut, und alle anderen im Forum sind total doof 
und voll gemein, daß sie seiner g~ttgleichen Lichtgestalt nicht huldigen 
-- und nicht einmal den Boden anbeten, auf dem er voll elfengleicher 
Anmut lustwandelt.

Daß die ablehnende Haltung vieler Teilnehmer dieses Forums (mit Ausnahme 
eines gewissen Dieter, der hier ebenfalls als eins von G~ttes besonderen 
Geschöpfen bekannt geworden ist) natürlich etwas mit seinem eigenen 
Verhalten zu tun hat, das kann und darf (siehe dazu auch bei Christian 
Morgenstern: "Die unmögliche Tatsache") natürlich nicht sein. Im 
Gegenteil ist das pure Blasphemie! Denn siehe, alle sind böse und gemein 
zu ihm, ganz ohne irgendeinen Anlaß und, vor allem, gänzlich ohne 
jedweden Grund.

Also knie nieder, Du elendiger Wurm, in den Staub mit Dir! :-)

[Christoph Z. (christophz)]

Danke fürs verlinken des Artikels und Posters.
Über Stärken und Schwächen verschiedener Systeme zu Diskutieren bzw. 
untereinander zu vergleichen, wie sie im Altag eingesetzt werden finde 
ich sehr gut und passt gut hier hin.

Bradward B. schrieb:
> Der Autor geht davon aus, das es im FPGA-Bereich nicht sinnvoll ist, im
> Alltag benötigte Compilate aus den versionierten HDL-Quellen zu
> erzeugen, sondern diese (oft Binaries) genannten Artifakte müssen (in
> der FPGA-Entwicklung) mit im Depot abgelegt werden. Das macht aus einer
> Quell-Code-Verwaltung eine File-Verwaltung, die auch reports, logs etc.
> einbezieht.

OK, ich kann einigermassen nachvollziehen, woher der Wunsch kommt, mehr 
als nur Source code verwalten zu wollen. Die genannten Limiten und 
Probleme sind dann schon direkt erwartbar, weil auch gut Dokumentiert, 
das man genau dies nicht mit GIT lösen soll.

Wir hatten zwar etwas andere "Pain points" als der Autor aber wir haben 
letztes Jahr bei uns auch die Git Submodules durch ein separates Tool 
zur Library/Abhänigkeitsverwaltung ersetzt. Benutzt unten drin immer 
noch Git aber halt mit mehr drumherum und löste unsere Probleme:
https://github.com/pulp-platform/bender

Bei uns im Git (und das wäre bei mir mit jeder anderen Source Code 
Verwaltung auch so) liegen nur Primärquellen. Alles was generiert wird 
wird im Toolflow (Makefiles, TCL und Python Scripts) automatisch 
erstellt oder erneuert wenn sich die Quellen geändert haben. 
Üblicherweise ist kein "make clean && make" nötig und ich kann zwischen 
Produkte wie erwartet weiter nutzen und Zeit sparen.
Dazu haben wir auch unsere Constraints gesplittet. Synthesizer (Clock, 
false-path etc.), Placer&Route (Location/Region, I/O Pins) haben 
einzelne constraint files. Also wenn ich z. B. nur einen I/O Pin ändere, 
wird die Synthese automatisch übersprungen, weil sich dort ja nichts 
geändert hat.

Zur Verwaltung, Speicherung und Sicherung von Binärfiles, Compilaten, OS 
Images etc. gibt es andere Produkte und Systeme. Ist ja auch kein 
unübliches Problem in der Softwareentwicklung. Da werden auch Releases, 
Deb/APK Packete, OS Images gebaut und verwaltet.
Einfach um mal als Beispiel einen Toolnamen genannt zu haben (Ist in 
unserer Firma im Einsatz aber nicht in unserem Team): 
https://jfrog.com/de/artifactory

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

Danke für die Einblicke in den Firmen/Profi-Bereich.

Bezüglich Aufspaltung constraint-files (*.xdc) zwecks 
Synthesestart-Vermeidung:
> Dazu haben wir auch unsere Constraints gesplittet. Synthesizer (Clock,
> false-path etc.), Placer&Route (Location/Region, I/O Pins) haben
> einzelne constraint files. Also wenn ich z. B. nur einen I/O Pin ändere,
> wird die Synthese automatisch übersprungen, weil sich dort ja nichts
> geändert hat.

OK, ich verstehe das so, das hier bekannt ist, das der built-Prozess bei 
FPGA in mehrere (zeitinsenive) Teilprozesse zerfällt (Synthese, mapping, 
place&route, physical optimisation, bitgen generation) und durch die 
Teilung der Gesamtmenge der sourcen, kann man in unterschiedliche Phase 
einspringen, da sich nur der für den späteren Subprozess in der 
built-kette relevante Source-Anteil ändert. Also wenn man nur 
IO-Paramter wie Treiberstärke, Pulls, etc ändert muss man lediglich das 
bitfile neugenerieren.

Bezüglich Trennung Source/Compilate:
> Zur Verwaltung, Speicherung und Sicherung von Binärfiles, Compilaten, OS
> Images etc. gibt es andere Produkte und Systeme. Ist ja auch kein
> unübliches Problem in der Softwareentwicklung.

Ich geh davon aus der der Posterautor nur einem "Produkt/Kunde" supporte 
(Grossforschungsanlage) und dadurch weniger mit Roll-out wie in der 
Industrie zu tun hat. Und ja, einige der angesprochenen "Pain points"
sollten in der Hobbyisten-Einzelkämpfer-Szene weniger wichtig sein.

[Rbx (rcx)]

Bradward B. schrieb:
> 
https://indico.cern.ch/event/1549296/contributions/7012275/attachments/3278140/5859467/SVN_vs_GIT_FDF26_Poster_final2.pdf

Mir ist nicht ganz klar, wie man so eine durchaus lesenswerte 
Wissenschaft in so ein bescheuertes Pdf packen kann.

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

> Mir ist nicht ganz klar, wie man so eine durchaus lesenswerte
> Wissenschaft in so ein bescheuertes Pdf packen kann.

Das ist auf einem wissenschaftlichen Kongress nicht ungewöhnlich sobald 
mehr abstracts eingereicht werden als Rede-slots eingeplant sind.

Dann bittet man die akzeptierten Autoren ein Poster anzufertigen, in dem 
die Ergebnisse kurz vorgestellt werden. Üblich sind 600-800 Wörter auf 
A0, hier ist es zu einer "Bleiwüste " geraten, die aber  IMHO durchaus 
lesbar ist.

Ein Bezeichnung als "bescheuert" ist da völlig fehl am Platze.

* https://de.wikipedia.org/wiki/Postersession

[Rbx (rcx)]

Bradward B. schrieb:
> Ein Bezeichnung als "bescheuert" ist da völlig fehl am Platze.

Sieht aber trotzdem bescheuert aus auf kleineren Bildschirmen. 
Diesbezüglich kann man dafür auch alternative Pdfs erstellen - gerade 
deswegen. Schließlich muss sich Wissenschaft auch gut verkaufen - da 
kann man sicher anderer Meinung sein, aber eine ordentliche Aufmachung 
kann schon mehr als die halbe Miete sein.
Auf der anderen Seite wird es aber gerade anrüchig, wenn es ein wenig 
pompös hergerichtet wird.

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

> Sieht aber trotzdem bescheuert aus auf kleineren Bildschirmen.

Dafür ist dieses Layout auch nicht gedacht - für 'kleine Bildschirme'.

Sondern für A0 (841 × 1189 mm) ausgedruckt und quer aufgehangen, so dass 
mehrere Personen in ca. 2 m Abstand davor stehend sich über das Thema 
"Quellcodeverwaltungssystem im FPGA-Bereich" austauschen können.

* https://paperpile.com/de/g/wissenschaftliches-poster-erstellen/
* 
https://www.uni-bremen.de/fileadmin/user_upload/sites/studierwerkstatt/Leitfaden_wissenschaftliche_Poster_erstellen.pdf

Es gibt da eine Empfehlung die Gesamtfläche im Verhältnis 50%:30%:20% 
für Text:Graphik:Leer aufzuteilen. Aber bewertet werden soll ja eher der 
Inhalt und nicht die Form.