IP und Projektmanagement

[Dominik Z. (dommynik)]

Hallo µCler,
ich arbeite seit neustem an einem relativ großen FPGA-Projekt, und habe 
mal wieder festgestellt, dass IP und Projektmanagement in der 
Hardware-Entwicklung kaum eine Rolle spielen. Projekte werden als Ganzes 
ins Repository eingecheckt, und wenn VHDL Module wiederverwendet sollen, 
dann werden die Quellen einfach kopiert und existieren somit mehrfach im 
Repository. Besonders im Bereich der Signalverarbeitung lohnt es sich 
ja, Funktionalitäten auszulagern und wiederzuverwenden. Wir haben einen 
Prototypen entwickelt, der externe Abhängigkeiten eines Moduls erkennt, 
aus SVN auscheckt. Haben zwei Module die selbe Abhängigkeit, gab es 
sofort Probleme, da die selbe Abhängigkeit zweimal zum Projekt 
hinzugefügt wird, und VHDL keine include guards hat. Jetzt entwickeln 
wir eine Möglichkeit, Module nur einmal auszuchecken - haben aber dann 
andere Pfad-Probleme, die noch zu lösen sind.

Nun zu meiner Frage: Wie handhabt ihr Projekte, Module, IPs in einem 
Versionierungssystem, automatischer Auflösung von Abhängigkeiten (evtl. 
mit Tag Checkout), usw. - hdlmake ist ein solches Projekt, welches 
leider nicht mehr aktiv entwickelt wird, und für unsere Toolchain 
(Lattice Diamond) mussten einige Änderungen getätigt werden, damit es 
überhaupt läuft.

Viele Grüße,
Dominik

[Selbständiger (Gast)]

Dominik Z. schrieb:
> dass IP und Projektmanagement in der
> Hardware-Entwicklung kaum eine Rolle spielen.

Das finde Ich aber seltsam, dass Du das festgestellt hast. Offenbar ist 
eure Firma da nicht so "firm". Sowas ist normal gut und gerne gelöst.

Da gibt es mehrere Alternativen und Methoden, wie man solche 
Mehrdeutgkeiten handhabt. Ich persönlich rate genrell davon ab, zu viele 
Verquickungen zwischen den Code-Elementen zu tolerieren.

Was an auto update und reuse sowie merge mit nativem C und C++ in der 
Softwarelandschaft funktioniert, scheitert beim FPGA meistens an dem 
Umstand, dass die tolls da nicht mitziehen und es anders lösen. Schon 
die Coregenratoren die jedesmal neu gestartet werden und bei einem 
update der software andere Ergebnisse produzieren, zerstören das!

Lösung:

Jedes Projekt bekommt seine eigenen Sourcen und die werden manuell genau 
dokumentiert. Ein update derselben wird nur nach req change gemacht und 
keinesfalls automatisch. Es gibt nichts Übleres, als das dauernde 
Einchecken von allenmöglichen Seiten, die dann irgedwas zerschießen.

[Christian R. (supachris)]

Wir haben die Quellen nach Projekt getrennt in jeweils einem Repo und 
alles was in mehreren Projekten verwendet wird, in einem extra Repo. 
Somit gibts keine Code Duplizierung. Da bei uns die Projekte zwar fast 
gleiche Funktion haben aber meist auf verschiedenen FPGA Typen laufen, 
bringt es nix die Xilinx Cores übergreifend zu benutzen.
Die VHDL Module müssen dann natürlich vorsichtig geändert werden, aber 
unsere FPGA Design Gruppe ist zum Glück nicht so groß.

[Duke Scarring (Gast)]

Dominik Z. schrieb:
> Besonders im Bereich der Signalverarbeitung lohnt es sich
> ja, Funktionalitäten auszulagern und wiederzuverwenden
Jein. Um eine Funktionalität so zu entwickeln, das alle möglichen 
Nutzungsszenarien abgedeckt sind, fehlt (mir) oft die Zeit.
Dann lieber die Quellen kopieren und die neuen benötigen Funktionen 
implementieren, wenn der Bedarf wirklich da ist.

VHDL kennt ja das Konzept der Librarys. Module die tatsächlich so 
universell sind, dass sie in vielen Projekten benötigt werden, kommen in 
eine zentrale Bibliothek. Per SVN-Externals wird das benötigte Modul 
dann im eigentlichen Projekt hinzugefügt. Mit SVN kann man auch auf ein 
Tag o.ä. verweisen, damit eine Weiterentwicklung des Moduls nicht das 
eigentliche Projekt kaputt macht (es reicht ja schon ein Signal in die 
Portliste aufzunehemen...).

Duke

[Strubi (Gast)]

Moin,

Duke's Ansatz kann ich auch untermauern, bin aber inzwischen auf git 
umgestiegen. Das hat vor allem mit der etwas agileren Branch-Verwaltung 
zu tun (welche solche Themen wie geänderte Port-Interfaces etc. 
abdeckt), aber da möchte ich keinem eine Meinung aufzwängen. Ist wohl 
ein Thema, was stark mit der Entwicklungsstrategie bzw. der 
Code-Organisation überhaupt zusammenhängt und sich über Jahre halt so 
entwickelt.
Was die Toolchain angeht: Manche Projekte werden hier teils per Makefile 
getestet/gebaut, aber wenn man auf die IDE der FPGA-Hersteller 
eingeschwungen ist, ist zumindest bei Lattice & Xilinx die 
TCL-Funktionalität ähnlich. D.h. welche Files bei welcher Konfiguration 
aus welchem Repo usw. geholt werden müssen, erledigt sich mit 
generierten TCL-Scripten relativ elegant.