Forum: FPGA, VHDL & Co. FPGA Entwicklung und SVN


von Michael S. (msb)


Lesenswert?

Ich bin eher in der Softwareentwicklung zu Hause und da ist SVN ein 
unentbehrliches Werkzeug um Sourcecodeänderungen zu verfolgen und 
mittels Taging jedes Release rekonstruieren zu können.

Bei VHDL Projekten sehe ich das genauso, jedoch gibt es da ein paar 
Hürden wie z.B. mit coregen erzeugte Sources. Ich möchte auf keinen Fall 
die generierten Dateien im SVN haben, sondern nur das, was man manuell 
erstellt hat. Auch finde ich es schlecht die corgen Einstellungen im 
Projektfile zu führen, weil das unübersichtlich bei der Verfolgung von 
Änderungen ist.

Meine heutige Lösung:
Die 2-3 Input Dateien für coregen werden im SVN geführt, jeder Core in 
einem Verzeichnis.
Ein Python script geht die Folder im SVN durch, prüft anhand des Datums 
welche cores neu generiert werden müssen. Zum generieren werden die 
Input Dateien in ein ausserhalb des SVN liegendes 
Generierungsverzeichnis kopiert und dort wird coregen aufgerufen. 
Optional können im spezifischen Teil des Scripts (wird auch in SVN 
gehalten)  textuelle Ersetzungen an den generierten Dateien durchgeführt 
werden.

Benutzt Ihr SVN für die FPGA Entwicklung?
Welche Tricks wendet Ihr an?

von Christian R. (supachris)


Lesenswert?

Ja, ich verwende SVN für meine sämtlichen FPGA Designs. Das mit dem 
Coregen ist kein Problem, da muss man nur die coregen.cgp und die *.xco 
bzw. *.xaw Dateien einchecken. Das sind Textdateien, aus denen sich alle 
Cores wieder erzeugen lassen. Lokal hab ich die Cores ja dann daliegen, 
auf dem TeamCity Server erzeuge ich die bei jedem Build mit, einfach per 
Command Line den Coregen aufrufen. Die Infos über die Cores liegen ja in 
den XCO Dateien, nicht im Projektfile. Jedenfalls bei Xilinx ISE. Bei 
Vivado kann das evtl. anders sein, weiß ich nicht. Aber prinzipiell muss 
man da keinerlei erzeugte Dateien einchecken.

von Klaus (Gast)


Lesenswert?

Wir benutzen auch eine Versionsverwaltung (GIT) für den FPGA Code. Das 
Problem mit den Cores lösen wir hauptsächlich dadurch dass wir den 
CoreGen gar nicht nutzen. Sondern die Module einfach direkt 
instantiieren und die passenden Generics angeben.

von Michael S. (msb)


Lesenswert?

Danke für die Antworten.

@Christian
Das nur 2-3 Dateien eingecheckt werden müssen ist mir klar.
Wo entstehen bei Dir denn die generierten Dateien?
Ich finde das störend wenn sich die generierten Dateien mit denen unter 
Versionskontrolle mischen.

von Christian R. (supachris)


Lesenswert?

Lokal landen die dann schon im gleichen Ordner, das stört schon bissl, 
stimmt, aber vollkommen getrennt geht bei ISE ja nicht wirklich, z.B. 
die xst und prj Dateien braucht man ja, wenn man die nicht selber 
schreiben und immer aktualisieren will, muss man auch die erzeugten von 
ISE nehmen, liegen dann auch im Projektverzeichnis. Die Source Files 
liegen bei mir auch getrennt  außer die für das jeweilige Projekt 
spezifischen. Auf dem Build Server wird dann ein clean checkout gemacht 
und alles komplett neu erstellt. Lokal kann man ja auch ein svn clean 
machen, wenn einem das zu unübersichtlich ist.

von Michael S. (msb)


Lesenswert?

Man sieht halt durch die vielen generierten Dateien nicht so gut welche 
Dateien man noch ins SVN bringen muss.
Das wäre alles einfacher, wenn man in coregen den Pfad für generierte 
Dateien angeben könnte.

von Christian R. (supachris)


Lesenswert?

Hm, naja, beim CoreGen ist es relativ einfach. Man braucht nur die cgp 
und dann für die Cores die xco. Hat man einfache DCM oder so auf den 
alten Spartan 3 erstellt, noch die xaw dazu, das wird aber dann mit 
xaw2vhdl erzeugt. Einen Ausgabepfad hab ich allerdings auch in der 
Command Line für den Coregen nicht gefunen.
Schlimmer ist eigentlich dass ISE beim "Cleanup project files" auch die 
xst, prj, ut Files usw mit löscht, die braucht man aber auch für den 
Command Line Build.

: Bearbeitet durch User
von Gerd E. (robberknight)


Lesenswert?

Michael S1. schrieb:
> Man sieht halt durch die vielen generierten Dateien nicht so gut welche
> Dateien man noch ins SVN bringen muss.

nimm git statt svn und gib Dir einmal Mühe ne passende .gitignore-Datei 
zu bauen.

Mit einem "git status"-Befehl siehst Du dann genau welche Dateien sich 
geändert haben oder dazugekommen sind. Die generierten werden komplett 
ausgeblendet solange Du sie nicht explizit manuell hinzufügst.

von Christian R. (supachris)


Lesenswert?

Gerd E. schrieb:
> nimm git statt svn und gib Dir einmal Mühe ne passende .gitignore-Datei
> zu bauen.

Auch bei SVN kann man Dateien oder ganze Ordner auf ignore setzen. 
Ändert aber nichts an der Tatsache, dass man erst mal wissen muss, was 
man ignorieren kann.

von J. S. (engineer) Benutzerseite


Lesenswert?

Ich checke nur das ein, was nach einem Project-Clean über bleibt, wobei 
das auch keine Garantie ist, dass man keinen unnützen Kram mit 
eincheckt. Man muss eben von Anfang an lernen und beobachten (und auch 
mal testen) ws man wirklich braucht.

Bei den Cores und den Project-Files mache ich es so, dass ich immer ein 
kleines Archiv erzeuge, wenn ich eine neue Version machen möchte. Dieses 
(und nur dieses !) ist ge-added und wird mit einem checkin mitgenommen. 
Damit verhindere ich, dass andere einen checkout machen, das Projet 
simulieren oder synthetisieren und dann veräanderte Projectfiles rot 
bekommen und diese unbeabsichtigt einchecken.

Dasselbe klappt auch bestens mit ModelSIMs Dateien wie mpg, do etc.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.