Creating a Versioned Repository for VHDL Files

[Altera_Forum]

Greetings All: 

Continually I create VHDL FPGA projects as required. In the projects, I create several .vhd files, some are specific for that project, some can be used in pretty much any project later, however sometimes they get some modification.    For instance, I created a clock_generator.vhd for dividing the main clock to produce a slower clock. That has been used in many other projects. Of course in some projects, the simple clock divider wasn't exactly what I needed, so modified it. I added 'clock enable' ports in and out, changed generics from 'divide_by' to 'clock_in_rate' and 'clock_out_rate' using 'real' type, and a few other things as time progressed.   Now if I start another project, with more than 1 version available it gets difficult to find/copy/paste the file into another project. Bug-fixing is not applicable to other copies as well. At one time I received an interesting suggestion...    --- Quote Start ---  Your code should live in a versioned repository and all projects should refer to the *single* copy of the source code. The generics would be controlled by either the project specific HDL via the instance generics, or any top-level generics would be controlled by your synthesis script, i.e., from Tcl code.  --- Quote End ---   http://www.alteraforum.com/forum/showthread.php?t=48216&highlight=#4   I completely agree with the suggestion, it sounds way better than the 'trying-to-find-the-best-most-up-to-date-clock_generate.vhd-file' I'm doing currently. And the 'versioned' part is required because if I have to recompile an old project that uses the first version, it may not be that compatible with the '47th' version I have now. So it still needs to be referenced to that particular reversion file (unless purposefully updating that as well).   Is there any information on file organization, I haven't heard any reference to that regarding to VHDL.  David K.

[Altera_Forum]

--- Quote Start ---  Greetings All:  Continually I create VHDL FPGA projects as required. In the projects, I create several .vhd files, some are specific for that project, some can be used in pretty much any project later, however sometimes they get some modification.    For instance, I created a clock_generator.vhd for dividing the main clock to produce a slower clock. That has been used in many other projects. Of course in some projects, the simple clock divider wasn't exactly what I needed, so modified it. I added 'clock enable' ports in and out, changed generics from 'divide_by' to 'clock_in_rate' and 'clock_out_rate' using 'real' type, and a few other things as time progressed.   Now if I start another project, with more than 1 version available it gets difficult to find/copy/paste the file into another project. Bug-fixing is not applicable to other copies as well. At one time I received an interesting suggestion...   http://www.alteraforum.com/forum/showthread.php?t=48216&highlight=#4   I completely agree with the suggestion, it sounds way better than the 'trying-to-find-the-best-most-up-to-date-clock_generate.vhd-file' I'm doing currently. And the 'versioned' part is required because if I have to recompile an old project that uses the first version, it may not be that compatible with the '47th' version I have now. So it still needs to be referenced to that particular reversion file (unless purposefully updating that as well).   Is there any information on file organization, I haven't heard any reference to that regarding to VHDL.  David K.  --- Quote End ---    Download svn(Tortoise svn). It is industry's de facto version control software. It is free but meant for servers.You can also use it on your pc without server.

[Altera_Forum]

The features you are looking for are supported by many versioning tools.  

 When you complete a project you can "tag" your repository, or multiple repositories, which allows you to return to that "instant in time" at some later date.  If you create a system where you "build" all of your projects all of the time, eg., simulate and synthesize after each code checkin or every evening, then you'll rapidly catch cases where you modify a common component used in an older design. Ideally you'd write unit tests for components, and board-level testbenches for your designs. The build system can then run the testbenches. If the testbenches run ok, then the component changes you just checked in are ok. If not, then this allows you to upgrade any existing (older) project to use the new component (or new features), even if you no longer have access to the hardware.  Having good testbenches saves you hours and hours of remembering what you've done or how you are supposed to use a component. It also saves you explaining it to someone else, 'cause you can give them the testbench (and hopefully some documentation, but lets not get carried away here ...)  Cheers. Dave