mikrocontroller.net

Forum: FPGA, VHDL & Co. Projekt VHDL-Code Datenbank


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich führe für mich und vereinzelt auch für Kundenprojekte eine Liste von 
Files, in der alle HDL-Quellen gelistet sind - nach Projekt, SW-Version, 
HW-Version, etc aufgeteilt. Das wird allerdings größer und immer 
unübersichtlicher, daher wurde das zwischenzeitlich in eine einfach 
Access-DB überführt. Ich überlege nun, das zu einem Projekt zu machen.

Eine alte Datenbank, die ich seinerzeit mal für C-Code gemacht hatte, 
soll dafür verwendet werden. Sie müsste allerdings umgebaut werden, weil 
sie für VHDL, deren Strukturen und Code-Vernetzung nicht 100% taugt. Ich 
überlege nun, die zu nehmen, eine VHDL-Erweiterung zu machen und somit 
auch C-Sourcen verwalten zu können. Z.B. soll man diese linken zu 
können, damit man System-C und andere Quellen, z.B. für Zynq, damit 
verwalten kann.

Man könnte dann ein Projekt definieren und versionieren, alle Sourcen 
zuordnen und hätte eine einfache Möglichkeit, die Stände und Versioen zu 
verwalten und sich jederzeit eine Übersicht geben zu lassen, welche 
Source-Version jeweils benötigt wird. Jede Source hat link-Möglichkeiten 
auf eine Ursprungsquelle, von der sie gfs abgeleitet wurde. Damit hat 
man mit einem Klick alle Derivate und Projekte in einer Liste, in der 
die Source oder ihre Kinder verwendet wurden. Damit gibt es sofort auch 
eine Übersicht über verwendete header und functions und kann sehen, ob 
es da Inkonsistenzen gibt, welche Verzeigerungen gfs fürs das neue 
Projekt falsch sind und vor allem auch, welche files veraltet sind und 
nicht mehr benötigt werden. Jede Source ist charakterisierbar, d.h. 
maturity, Entwicklungs- und Teststatus sind ersichtlich.

Die DB würde ich dann allen zugänglich machen und wäre für private 
Nutzung kostenlos. Angedacht ist ein Frontend-Back-End-System, sodass 
man einfach die GUI, Abfragen und Berichte im Fall von Erweiterungen und 
Verbesserungen austauschen kann.

Hätte jemand Interesse, daran mitzuwirken und Input zu geben, was 
benötigt wird?

: Verschoben durch Moderator
von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das klingt für mich nach so eine Art 'Opencores' nur mit mehr Vernetzung 
zwischen den Teilprojekten.
Bzw. eine Funktionalität, wie sie svn-externals bietet.

Klingt auf jeden Fall interessant, aber auch nach relativ hohem 
initialen Aufwand.

Ich glaube dafür überschneiden sich bei mir die Projekte nicht 
ausreichend genug.

Duke

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich wuerde eher eine Infrastruktur nehmen die es schon gibt. Z.B. Python 
PiP oder PHP Composer. Wobei ich eher zu PiP tendieren wuerde.

: Bearbeitet durch User
von Gustl B. (gustl_b)


Bewertung
0 lesenswert
nicht lesenswert
Kann man eigentlich seine eigenen Komponenten z. B. bei Vivado in den IP 
Katalog einpflegen? Oder muss das von Xilinx geschehen? Das wäre ja doch 
recht schick.

Ich stelle mir das so vor, dass man sich an eine Ordnerstruktur von 
Xilinx halten muss und dann noch eine Datei für den Wizard anlegt nach 
einem Standard. Aber dann gibt man einem neu installieren Vivado einfach 
einen Pfad und alle eigenen IPs tauchen auf.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Gustl B. schrieb:
> Kann man eigentlich seine eigenen Komponenten z. B. bei Vivado in den IP
> Katalog einpflegen? Oder muss das von Xilinx geschehen? Das wäre ja doch
> recht schick.

Ja, man kann in jedem Projekt Pfade zu zusätzlichen IP-Repositories 
hinzufügen. Dies geht sowohl über den IP Integrator als auch per
"set_property ip_repo_paths".

Ich bin nicht unbedingt ein so großer Freund von IP-Respositories, da es 
zwei wesentliche Einschränkungen gibt:

- keine Unterstützung von VHDL 2008 in IP-Blöcken
- umständliches Entpacken/Packen von in der Weiterentwicklung 
befindlichen IP-Blöcken

Grundsätzlich ist es zwar eine nette Idee, dass auch Firmware-Treiber in 
IP-Blöcken enthalten sein können, aber während der Entwicklung solch 
eines Treibers ist es unglaublich lästig, einen Umweg über den IP 
Packager machen zu müssen. So etwas eignet sich nur für wirklich 
"fertige" Treiber, d.h. für IP-Blöcke, die man explizit an Dritte 
liefert. Für den Eigenbedarf ist das häufig eher nur umständlich.

In vielen Fällen bevorzuge ich es daher, externe VHDL-Quellen als sog. 
"HDL Module" im Vivado-Blockdesign hinzuzufügen. Dies geht auch ganz 
ausgezeichnet mit AXI-Peripherieblöcken, die man mit Hilfe des 
entsprechenden Wizards angelegt hat und die auch völlig korrekt in der 
AXI-Adresstabellle auftreten und mittels HSI an das zugehörige 
SDK-Projekt gemeldet werden.

Ich kann mir vorstellen, dass Jürgen S. auch derartige Quellen meint.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich wuerde beim heutigen Wissenstand arg dazu tendieren, gitlab minimal 
aufzubohren. Sprich: git ist die Datenbank. Bloss nicht sowas neu machen 
(been there..), was fuer Software schon lange tut, geht auch fuer HW.

Die Wartung einer manuell gefuellten Datenbank wird schnell mal zur 
immensen Arbeit, wenn man Aenderungen vornimmt, die sich irgendwie 
propagieren. Das erledigt man besser mit einer kontinuierlichen 
Integration fuer alle abgedeckten Konfigurationen (oder spezifische 
Projekte).
Da gibt es eine Menge unterschiedlicher Strategien, diese 
Konfigurationen zu beschreiben (kconfig, XML, [Strict]YAML, ...). Das 
laesst sich nicht so einfach/elegant in einer tabellarischen Datenbank 
abbilden.

Was es allerdings m.W. so noch nicht gibt:
eine GUI, bei der man sich eben mal die verschiedenen Testszenarien 
schnell zusammenklicken koennte, wie:
Bau mir mal eben board supply 'knorpelpeter' mit IP cores aus LibMurks 
mit Branches 'test', 'master', 'v0.1' plus Firmware 'unstable' und spuck 
mir PASS/FAIL aus. Und bei Klick den ganzen Test-Report.
Und das erst mal im 'dry-run', ohne gleich einen Commit machen zu 
muessen.
Wenn das das geht, bekommt das Ding einen 'working' tag und wird 
automatisch gepusht (inkl. nachgefuehrte Abhaengigkeiten von den 
entsprechenden Versionen in den git-submodulen). Die PASS/FAIL-Matrix 
(was mit was laeuft) koennte natuerlich in eine Datenbank um daraus 
Web-Reports zu generieren.

Was sonst VHDL-Source-Analyse, DRC und korrekte Aufloesung der 
Interfaces angeht, kann man mit GHDL/XML viel machen. Laesst sich auch 
gut in gitlab-Pipelines integrieren.

: Bearbeitet durch User
von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Was es allerdings m.W. so noch nicht gibt:
> eine GUI, bei der man sich eben mal die verschiedenen Testszenarien
> schnell zusammenklicken koennte, wie:
> Bau mir mal eben board supply 'knorpelpeter' mit IP cores aus LibMurks
> mit Branches 'test', 'master', 'v0.1' plus Firmware 'unstable' und spuck
> mir PASS/FAIL aus. Und bei Klick den ganzen Test-Report.
> Und das erst mal im 'dry-run', ohne gleich einen Commit machen zu
> muessen.

10 PRINT "FAIL"

Das war einfach!
SCNR

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Danke schon einmal für die bisherigen Antworten. Ich kenne natürlich die 
tools für die Versionsverwaltung und auch deren Möglichkeiten. Diese 
decken aber nach meiner Kenntnis nicht die Möglichkeiten ab, die ich 
anstrebe. Was man natürlich andenken könnte, wäre eine Art Anbindung. 
Z.B. könnte man SVN-tags extrahieren und hinterlegen, katalogisieren und 
suchbar machen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Z.B. könnte man SVN-tags extrahieren und hinterlegen, katalogisieren und
> suchbar machen.

Das ist genau das was du mit PiP oder Composer erreichst, nur eben auf 
Basis von Git (SVN koennte auch unetrstuetzt sein, habe ich noch nie 
probiert).

Eine einfacherer Moeglichkeit (die allerdings mehr Handarbeit erfordert) 
waere mit Git Submodules zu arbeiten.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Git ist nur für Textdateien sinnvoll und ein Versionierungssystem, keine 
Datenbank. Wenn der Datenbestand bisher sinnvoll in Access gepflegt 
werden kann, dann wäre eine relationale Datenbank vielleicht sinnvoll.

Meine Empfehlung wäre SQLite, weil man das wunderbar in eigene Programme 
einbinden kann und keine nennenswerten Abhängigkeiten hat. Wenn das ein 
Web-Dienst werden soll, lässt sich das SQL (wenn man aufpasst) auch 
einfach migrieren.

Soweit ich das einschätzen kann, geht es hier nicht darum, eine 
Versionsmatrix zu versionieren, sondern um einen aktuellen Stand zu 
pflegen.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Aber genau den Sinn dieser Datenbank verstehe ich nicht. Man hat ein 
VHDL Projekt, welches andere Projekte als Abhaengigkeiten hat. Diese 
Abhaengigkeiten wuerde man jetzt z.B. via PiP in die requirements.txt 
schreiben (welche Projekt in welcher Versionsnummer soll eingebunden 
werden).

Die Datenbank wuerde dann Sinn machen, wenn man z.B. Metriken erstellen 
moechte welches Projekt wie oft eingebunden wurde oder ob ein veralteter 
Versionsstand vorliegt.

Wenn ich es aber richtig verstanden habe geht es aber nicht darum 
Projekte zu analysieren sondern aufzusetzen.

von Martin S. (strubi)


Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:
> Git ist nur für Textdateien sinnvoll und ein Versionierungssystem, keine
> Datenbank. Wenn der Datenbestand bisher sinnvoll in Access gepflegt
> werden kann, dann wäre eine relationale Datenbank vielleicht sinnvoll.
>

Hinter git steckt genau die Objekt-Datenbank, die man's fuer's Tracken 
und fuer diese ganzen Operationen der Versionifizierung, Abhaengigkeiten 
usw. braucht ('git, the stupid content tracker'). Und natuerlich kann 
man das auch fuer Binaerdateien nutzen. Nur textbasiertes 'diff' macht 
dann nur bedingt Sinn (dafuer gibt's Plugins).
Ich checke z.b. auch mal PDFs ein, die werden dann halt durch diffpdf 
gekloppt.


> Meine Empfehlung wäre SQLite, weil man das wunderbar in eigene Programme
> einbinden kann und keine nennenswerten Abhängigkeiten hat. Wenn das ein
> Web-Dienst werden soll, lässt sich das SQL (wenn man aufpasst) auch
> einfach migrieren.
>

SQLite wirft einfach irgendwann den Bettel hin, wenn man einen riesigen 
Baum verwalten muss, wie z.b. ein Linux-BSP mit verschiedenen Branches 
gegen div. Hardware-Konfigurationen. Bei meinem Versuch damals war das 
irgendwann nicht mehr skalierbar/anwendbar.
SVN sollte man fuer sowas erst gar nicht anfangen zu verwenden. Da gibt 
es schon fundamentale Probleme mit externals und die Branchverwaltung 
ist auch nicht skalierbar. Git ist einfach auch fuerchterlich schnell, 
was sich in der CI bei n * m Komplexitaet bemerkbar macht.

Tobias B. schrieb:
> Eine einfacherer Moeglichkeit (die allerdings mehr Handarbeit erfordert)
> waere mit Git Submodules zu arbeiten.

Genau das ist eigentlich Stand der Methodik. Das sollte man nicht mehr 
neu erfinden. Hoechstens Tools druebersetzen, die das Management fuer 
'lazy developers' leichter machen. git ist als Lowlevel-Tool zwar fuer 
den Anwender eine echte Sau, weil's oft auch zuviele Wege zum Ziel gibt. 
Aber es gibt halt so gut wie nichts, was damit nicht geht.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Genau das ist eigentlich Stand der Methodik. Das sollte man nicht mehr
> neu erfinden. Hoechstens Tools druebersetzen, die das Management fuer
> 'lazy developers' leichter machen. git ist als Lowlevel-Tool zwar fuer
> den Anwender eine echte Sau, weil's oft auch zuviele Wege zum Ziel gibt.
> Aber es gibt halt so gut wie nichts, was damit nicht geht.

Das einzigste was mich bei den Submodules nervt (was allerdings nicht an 
Git liegt), ist, dass man relative Pfade braucht wenn das korrekt mit 
Gitlab zusammenarbeiten soll. Daher muss man immer die .gitmodules von 
Hand anfassen. [1]

Gibt es da evtl. einen eleganteren Weg, z.B. eine Git Config damit Git 
automatisch die absoluten Pfade relativ macht?

[1] https://docs.gitlab.com/ee/ci/git_submodules.html

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Ich nutze aus Prinzip nur relative Pfade, wenn multi-user. Man kann mit 
pre-commit hooks dreckige Sachen machen, aber wenn du lokal absolute und 
'upstream' relative Pfade unterhalten willst, wuerde ich das per branch 
machen ('local' branch enthaelt nutzerspezifische Pfade und 
Cfg-Dateien). Dann hast du halt bisschen Merge-gezuppel.
Oder symbolischen Link innerhalb des relativen Unterverzeichnis des 
submodule zum absoluten setzen. Das ist dann halt bisschen gefaehrlich, 
wenn man lokal ne Pipeline aufsetzt, bei der unterschiedliche 
Entwicklungszweige bauen, die wiederum von unterschiedlichen 
submodul-Zweigen abhaengig sind, aber dann auf das gleiche Verzeichnis 
zeigen..

von Christoph Z. (christophz)


Bewertung
1 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Das einzigste was mich bei den Submodules nervt (was allerdings nicht an
> Git liegt), ist, dass man relative Pfade braucht wenn das korrekt mit
> Gitlab zusammenarbeiten soll. Daher muss man immer die .gitmodules von
> Hand anfassen. [1]
> [1] https://docs.gitlab.com/ee/ci/git_submodules.html

Martin S. schrieb:
> Ich nutze aus Prinzip nur relative Pfade, wenn multi-user. Man kann mit
> pre-commit hooks dreckige Sachen machen, aber wenn du lokal absolute und
> 'upstream' relative Pfade unterhalten willst,

Martin, schau dir mal den gitlab doku link an. Hier geht es nicht um 
absolute/relative Pfade sondern um absolute/relative URLs.

Habe dabei auch etwas neues gelernt, danke. Ist noch nicht aktuell aber 
Gitlab CI steht bei uns auf dem TODO.

Tobias B. schrieb:
> Die Datenbank wuerde dann Sinn machen, wenn man z.B. Metriken erstellen
> moechte welches Projekt wie oft eingebunden wurde oder ob ein veralteter
> Versionsstand vorliegt.

Da wir eh schon Gitlab haben, wäre es super wenn wir diese Information 
gleich da drin bekommen würden. Gibt es leider nicht, wünschen sich aber 
andere auch: https://gitlab.com/gitlab-org/gitlab/issues/21719

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Martin, schau dir mal den gitlab doku link an. Hier geht es nicht um
> absolute/relative Pfade sondern um absolute/relative URLs.

Genau, vielen Dank. Da hab ich mich echt schlecht ausgedrueckt. :-(

Christoph Z. schrieb:
> Habe dabei auch etwas neues gelernt, danke. Ist noch nicht aktuell aber
> Gitlab CI steht bei uns auf dem TODO.

Falls du ein CI Beispiel brauchst mit VHDL und Python Support, kannst 
mal hier reinschauen:

https://gitlab.com/Elpra/drever-framework/drever

Christoph Z. schrieb:
> Da wir eh schon Gitlab haben, wäre es super wenn wir diese Information
> gleich da drin bekommen würden. Gibt es leider nicht, wünschen sich aber
> andere auch: https://gitlab.com/gitlab-org/gitlab/issues/21719

Danke fuer den Link, hab gleich mal ein Up-Vote dagelassen. Ich schaetze 
bis das implementiert ist dauert es ewig bis nie. Wahrscheinlich muss 
man da fast selbst ran und entsprechend nenn MR absetzen um zu Lebzeiten 
noch etwas von dem Feature zu haben. :-(

: Bearbeitet durch User
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Martin, schau dir mal den gitlab doku link an. Hier geht es nicht um
> absolute/relative Pfade sondern um absolute/relative URLs.

Wenn ich das jetzt richtig ueberflogen habe, geht's darum um den 
checkout vor dem Start des Containers/runners. Ich checke da nur ein 
Minimum fuer die build-Umgebung aus und ziehe mir dann der Rest im 
laufenden Container, da natuerlich mit absoluten URLs oder wenn 
konfig-Option per Environment-Variable.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich meine auch Gitlab selbst braucht relative URLs damit die 
Verlinkungen zu den Submodule Repositories innerhalb einer Gitlab 
Instanz entsprechend funktionieren.

Martin S. schrieb:
> Ich checke da nur ein
> Minimum fuer die build-Umgebung aus und ziehe mir dann der Rest im
> laufenden Container, da natuerlich mit absoluten URLs oder wenn
> konfig-Option per Environment-Variable.

Hat entsprechend den Nachteil, dass dein Container auch Git 
Unterstuetzung braucht. Relativ viele, vorallem minimalistische Docker 
Images, haben aber kein Git mit dabei. Entsprechend musst du dann 
jedesmal Git on-the-fly installieren oder ein Image warten, dass Git 
Unterstuetzung hat.

Beides jetzt kein Hexenwerk, aber unnoetige Arbeit ist es halt trotzdem.

: Bearbeitet durch User
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Beides jetzt kein Hexenwerk, aber unnoetige Arbeit ist es halt trotzdem.

Ein einmaliges
> apt-get install git
im Dockerfile?


Meine CI-Strategie ist grundsaetzlich, das System in der Umgebung 'from 
scratch' zu bauen/testen, in der es auch eingesetzt wird, gerade wenn 
Abhaengigkeiten von verschiedenen Tools/Repos vorliegen. Minimalistisch 
ist dabei eh kein Kriterium mehr.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Ein einmaliges
>> apt-get install git
> im Dockerfile?

Verwendest du wirklich ein eigenes Dockerfile pro Projekt und baust dir 
deinen Container immer aufs neue von vorne?

Sinnvoller waere es die Images fuer Unit-Tests und Firmware Builds 
separat zu pflegen. Und genau diese Pflege kann man sich in manchen 
Faelle halt sparen wenn man ein fertiges Image auf Dockerhub findet und 
eben nicht jedes dieser Images hat Git Support.

Von daher bleiben dir genau 3 Moeglichkeiten:

1.) Bei jedem Run Git im neu aufgespannten Container installieren.
2.) Ein Image Repo Pflegen (Git via Dockerfile installieren, Image bauen 
und ins Repo einpflegen - Vorgang wiederholen bei Updates vom Parent 
Image oder auch dafuer einen Build Prozess aufbauen)
3.) Den Git Support von Gitlab nutzen

Punkt 2 macht regelmaessig Arbeit, Punkt 1 braucht entsprechend Server 
Kapazitaeten und skaliert entsprechend schlecht mit der Anzahl von 
Commits / Usern.

Kleiner Nachtrag: Punkt 2 ist fuer FPGA Projekte natuerlich deutlich 
weniger Aufwand, die die Software Abhaengigkeiten entsprechend gering 
sind und auch nicht wahnsinns schnelllebig was Updates betrifft.

: Bearbeitet durch User
von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
@Tobias:

>
> Verwendest du wirklich ein eigenes Dockerfile pro Projekt und baust dir
> deinen Container immer aufs neue von vorne?
>

Nicht zwingend pro Projekt, aber das Mutter-Image ist in einer gewissen 
Pipeline Teil der CI.

> Sinnvoller waere es die Images fuer Unit-Tests und Firmware Builds
> separat zu pflegen. Und genau diese Pflege kann man sich in manchen
> Faelle halt sparen wenn man ein fertiges Image auf Dockerhub findet und
> eben nicht jedes dieser Images hat Git Support.
>

Wuerde jetzt etwas zu ausfuehrlich - in Kuerze: Der Builder baut sich 
selbst und testet sich auch selbst. Sonst haette ich mehr 
Management-Overhead.
Ich setze natuerlich auf einem Standard OS auf, da muessen sowieso ein 
paar Tools installiert werden. Ob da jetzt noch git zukommt...

Der Knackpunkt ist aber, dass einige Submodule auf eine 'selektive' 
Weise eingebunden werden. Da moechte ich nicht mit gitlab rumfummeln, 
das kann das Buildsystem (im Container) besser.

> Von daher bleiben dir genau 3 Moeglichkeiten:
>
> 1.) Bei jedem Run Git im neu aufgespannten Container installieren.
> 2.) Ein Image Repo Pflegen (Git via Dockerfile installieren, Image bauen
> und ins Repo einpflegen - Vorgang wiederholen bei Updates vom Parent
> Image oder auch dafuer einen Build Prozess aufbauen)
> 3.) Den Git Support von Gitlab nutzen
>
> Punkt 2 macht regelmaessig Arbeit, Punkt 1 braucht entsprechend Server
> Kapazitaeten und skaliert entsprechend schlecht mit der Anzahl von
> Commits / Usern.
>

Nicht so kompliziert...
Die Arbeit bei 2), wenn Paket-Updates noetig (die seltener releast 
werden), geht gegen Null..ist ja Teil der CI. Der Container mit aller SW 
wird nur (auto-)gepusht, wenn der Regresstest durchlaeuft.

> Kleiner Nachtrag: Punkt 2 ist fuer FPGA Projekte natuerlich deutlich
> weniger Aufwand, die die Software Abhaengigkeiten entsprechend gering
> sind und auch nicht wahnsinns schnelllebig was Updates betrifft.

Gerade wegen der SW-Abhaengigkeiten nutze ich Methode 2, wenn irgendwo 
was schepplaeuft, sieht man das dann relativ zeitnah im "Badge Cockpit".

Das einzige 'Problem' bei submodule-Abhaengigkeiten ist, dass SM von 
Drittparteien bei Aenderungen die CI nicht unmittelbar triggern, sondern 
man das mit einem Hack (crontab checkt nach Aenderungen) selber 
ausloesen muss.

von Mark W. (kram) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Die Jungs aus Draeschdn machen da auch schon was:

https://github.com/VLSI-EDA/PoC

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
@Martin

Ok, dan ist da wirklich nichts Ungewoehnliches dabei, ausser dass eben 
der Checkout Prozess komplett manuel gehandelt wird (und auch eben 
innerhalb des Containers anstatt dass es als Cache gemountet wird).

Ist halt der Trade-Off zwischen Funktionalitaet und Komfort. Ohne extra 
Arbeit geht es in deinem Workflow sicher nicht, anderseits bist du halt 
auch flexibler. So richtig den Vorteil sehe ich allerdings noch nicht, 
kann mir aber schon vorstellen, dass das ind einem speziellen Fall seine 
Gruende hat. Etwas strange ist es trotzdem, zumal Gitlab eben Submodules 
unterstuetzt und die Unterstuetzung mit der Zeit sicher 
Nutzerfreundlicher wird, statt schlechter.

Mark W. schrieb:
> Die Jungs aus Draeschdn machen da auch schon was:
>
> https://github.com/VLSI-EDA/PoC

Das ist aber eher eine Sammlung von Design Patterns, als ein Management 
Tool fuer IPs oder?

von Mark W. (kram) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Mark W. schrieb:
>> Die Jungs aus Draeschdn machen da auch schon was:
>>
>> https://github.com/VLSI-EDA/PoC
>
> Das ist aber eher eine Sammlung von Design Patterns, als ein Management
> Tool fuer IPs oder?

Ja, ich dachte dass es fuer die Leute hier interessant ist, da ich es 
gerade beim Suchen entdeckt hatte und mich an diesen Thread erinnerte.
Ich dachte es ging um eine Datenbank fuer Code Vorlagen.
Ich habe es ganz einfach als Text in einem Ordner, einfacher geht es 
nicht.

P.S.: Manchmal bediene ich mich auch heimlich bei Lothar auf seiner 
Webseite. :-)

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Tobias B. schrieb:
> Etwas strange ist es trotzdem, zumal Gitlab eben Submodules
> unterstuetzt und die Unterstuetzung mit der Zeit sicher
> Nutzerfreundlicher wird, statt schlechter.

Oder anders: stell dir ein Build-System a la buildroot fuer 
Embedded-Systeme fuer Hardware vor. Je nach Kconfig-Option wird per git, 
svn, etc. (nur) gezogen, was gebraucht wird, allenfalls auf eine 
spezifische Revision festgezurrt (ev. mit Patch). Heisst, eine groessere 
Anzahl (~50) 'defconfig_platform-variant'-Dateien gibt die 
Konfigurationen vor.
Das steckt alles bereits im Container, selbiges auf gitlab-ci 
umzufrickeln waere eine fehleranfaellig YML-Orgie. Da halte ich die 
kconfig-Tools fuer stabiler. Oder: Running legacy no touchy!

Besagter Container (namens 'masocist') laesst sich auch in der 
OpenSource inspizieren, gibt dazu auch ein Beispiel mit RISC-V in der CI 
(oder im Browser):

https://section5.ch/index.php/2019/10/24/risc-v-in-the-loop/

Vielleicht sollten wir aber fuer die ganze CI-Diskussion doch nen 
anderen Thread auftun.

von Tobias B. (Firma: www.elpra.de) (ttobsen) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Martin S. schrieb:
> Besagter Container (namens 'masocist') laesst sich auch in der
> OpenSource inspizieren, gibt dazu auch ein Beispiel mit RISC-V in der CI
> (oder im Browser):
>
> https://section5.ch/index.php/2019/10/24/risc-v-in-the-loop/

Ok, alles klar. Werde ich mir mal ansehen. Ich verstehe jetzt auch den 
Workflow schonmal deutlich besser. Hier gehts weit ueber ein paar VHDL 
Sourcen hinaus. :-)

Martin S. schrieb:
> Vielleicht sollten wir aber fuer die ganze CI-Diskussion doch nen
> anderen Thread auftun.

Ja, das macht Sinn. :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.