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.
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
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..)
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.