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.
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.
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.
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).
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.
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
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.
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.
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.
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.
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.
Der Titel des Posters ist zu pauschal und nun ja, etwas kindisch trotzig. Die Kernaussage ist doch “Wir haben einen für uns gut funktionierenden Workflow mit Tool A geschaffen und den kann man mit Tool B nicht exakt nachbauen.”
Deswegen ist Tool B aber nicht allgemein schlecht für z.B. FPGA Entwicklung.
Gerade bei Versionsverwaltung, Build-Systemen u.ä. ist der Workflow meist eng mit dem jeweiligen Tool verzahnt. Ein Ersatz erfordert oft radikale Eingriffe. Wenn man das nicht möchte, und mit dem aktuellen Tool zufrieden ist, warum überhaupt wechseln? Viele erinnern sich gar nicht mehr an die Schwierigkeiten bei der Umstellung zu Tool A (vom mit all seinen Fehlern lieb gewonnenen Tool X).
Submodules sind in einem DVCS immer problematisch und sollten möglichst vermieden werden. Nested submodules sind der Horror, wenn man aktiv branching/merging/history-editing betreibt oder in verschiedenen Workspaces arbeitet. Am besten man hat ein reines Container repo, das die Build Konfiguration enthält und alle Module auf einer Hierarchie referenziert.
Ein submodule in unterschiedlichen Versionen in einem Projekt (siehe “Step 1”) ist natürlich auch mit (2) möglich, aber es fällt einem vermutlich früher oder später an anderer Stelle auf die Füße: “Ich dachte der Bug in B wär schon gefixt!”. Kein Problem des Tools sondern der Organisation.
Artefakte können im Falle von reproducible builds zentral abgelegt und referenziert werden. Das ist aber eigentlich keine Aufgabe der Versionsverwaltung und sollte sowieso durch einen build-bot erfolgen. Zu groß die Gefahr, dass ein menschlicher Benutzer Inkonsistenzen erzeugt.
Weshalb müssen merges zwingend manuell durchgeführt werden? Das ist doch auch nur lokale Policy und kein Naturgesetz. Man kann ja auch ‘--no-commit’ angeben und das Ergebnis erstmal prüfen.
Kein Projekt verlangt (“requires”) branching/merging. Aber es zwingt ja auch niemanden. Und wer es dennoch möchte, der kann es eben nutzen.
Warum sollte man als FPGA Entwickler nicht offline arbeiten können? Nicht jede Änderung erfordert rebuilds oder Zugriff auf Artefakte. Die Doku möchte auch mal aktualisiert werden :-)
Speicherplatz ist billig und man kann mit Git Workspaces noch etwas sparen.
Aber bewertet werden soll ja eher der
Inhalt und nicht die Form.
Prinzipiell ja - aber z.B. in der Zeitschrift "Nature" gab es hier und da Diskussionen rund um den wissenschaftlichen Ausdruck. Ist halt ein öfterer Konflikt. Man kann es analog vergleichen mit der Programmierung "foo" "bar" oder "ReglerA" oder "ReglerB" - das ist im Grund das gleiche Problem in der Wissenschaft. Unterm Strich geht es aber ums Veröffentlichen - und da zählt die Form auch nicht. Insofern hast du dann schon recht ;) Darüber hinaus weiß man auch viel mehr, wenn man viel Veröffentlicht.
Und Linus hat eine sehr polarisierende Sicht auf die verschiedenen spezifischen Versionsverwaltungen ... " I see Subversion as beeing the most pointless project ever started ..."
Evtl. kann man ja schauen ob Tools für Softwareentwicklung auch für die FPGA Entwicklung ertüchtigen kann.
Und dafür sollten die Entwickler und Designer solcher Tools die Probleme bei FPGAs auch verstehen.
Die Referenz diesbezüglich ist von 2007 - also nicht unbedingt aktuell ;)
2007 gab es eigentlich Linux auch noch nicht so lange. 2006 kam gerade Knoppix heraus und viele nutzten noch DSL. Zur Jahrtausendwende ('98) haben aber schon OpenSuse oder Debian vorne gelegen und bei der c't kam später in einem zynischen Editorial, dass Linux schwer angreifbar ist, wegen der vielen verschiedenen Varianten. Ubuntu kam dann 2008 ins Spiel und hatte für einen angenehmen Standard gesorgt.
SVNfitsFPGA.png
(41 KB)
