Version control for shared FPGA

sthenc Guest 2017-11-23 16:53 #5220169

Rate this post

•	▲ useful ▼ not useful

I would be very thankful for any advice or pointers regarding managing 
evolving FPGA IP with inter-dependencies. Our development process is 
pretty chaotic, and sticking to a process with fixed revisions of IP and 
release schedules is not a realistic option.

My company is in the process of moving to GIT as our VCS, but in the 
process we would also like to figure out a smart way to version 
components shared between projects. We have several utility packages, 
IPs and behavioral models that have evolved into different variations. 
In itself this is not a big problem, but bug fixes and enhancements tend 
to not propagate upstream (if there is a single referent version at 
all), and we had instances of trying to reuse IP from several different 
projects, only to find that they use incompatible versions of utility 
packages. The legacy IP probably can't be recovered from the mess that 
was inflicted, but we are developing a new IP family, and I would really 
like to get it right (or at least better) this time.

I would like to know if there is a workflow you would recommend?

I looked at git submodules/subtree/subrepo, but the learning curve seems 
a bit too steep for my coworkers. and I am not sure if it is worth it.

I would appreciate real-life experiences related to managing this 
problem, even if they are not GIT specific.

Reply Quote Edit Move Thread sperren Anmeldepflicht aktivieren Anpinnen Delete topic Thread mit anderem zusammenführen Report post

Duke Scarring Guest 2017-11-27 11:05 #5224422

Rate this post

•	▲ useful ▼ not useful

I use SVN with externals for such task.
In git I would use a separate repository for every IP core. With tags 
every porject can import a fix version of the IP core and allows to 
develop the IP core in trunk.

Duke

Reply Quote Edit Delete Report post

Strubi Guest 2017-11-27 23:04 #5225387

Rate this post

•	▲ useful ▼ not useful

If you already have the "mess", git and the submodule options are 
probably the best way to go in the process of cleaning up.
If you are in the position to influence/enforce the "next generation 
work flow" I would recommend to get into the submodule setup details 
anyhow, even if the initial "expense" is high. But I would only do that 
if the cores in the submodule is considered a clean library with (maybe 
automated) unit tests, so you can immediately see when things break. If 
changes are required, have the hacking happen on another branch...
The thing is, it can get really nasty when switching branches with 
corresponding external modules that are of a specific revision (like for 
buggy IP referred by a wrapper with workaround, so updating the bugfix 
will break everything upward). This is where SVN would force to more 
discipline, your team would need to stick to a possibly less 'agile' 
test/development strategy.
You'll definitely have to do the math for your IP collection and find 
out if it can be better maintained in a reasonable number of branches or 
better in the submodule 'library style' setup. On the other hand, you 
wouldn't want too many svn:external alike references.

> I looked at git submodules/subtree/subrepo, but the learning curve seems
> a bit too steep for my coworkers. and I am not sure if it is worth it.
>

If you can be (or make one guy) the git expert, you can fix up a lot 
later on by reorganizing branches the surgical way. In fact, I did quite 
a bit of cleanup work by just chucking the whole IP tree into one big 
repo, and then split off the common 'library' stuff into a cleaner 
separate repo, later used as submodule. This cleanup work is a lot 
harder to do in SVN (history is never forgotten..)