Version Control Software

I've just started looking into getting our VHDL code into some sort of
version control tool, and would like to get some information about
which ones work best with VHDL & FPGA tools.

All our designs are done using Actel Libero, and AFAIK it doesn't
provide any helpful features for version control. I have previously
used SourceSafe for a little while, but since we are just a small
company I think the cost is a bit much.

Our software team currently use PVCS, has anyone had any experience
using this with VHDL?

Neill A

I have to say that version control is pretty much orthogonal to what
programming language you're using, so long as you keep your programs
in text files that are broken into lines separated by carriage returns
(or line-feeds).

That in mind, I _emphatically_ recommend darcs.

http://abridgegame.org/darcs/

It won't coddle you with a GUI, but it has a higher
power-to-simplicity ratio than basically every other piece of software
I use on a daily basis. Actually there probably are GUIs for it if
that's what you want.

One killer feature is that it understands search-and-replace on
tokens, so if one person changes a line of code and another person
does a search-and-replace affecting a different part of the same line,
darcs will merge the two changes correctly without human intervention.

The other killer feature is that making and merging branches is
really, really easy to understand -- unlike a lot of other systems
where it's complex or hairy enough that people tend to never learn
about it. There's no client/server (or repository/workspace)
distinction in darcs; it's all peer-based. So to make a branch, you
just "check out" a copy and use that copy as the branch. Your
branches are directly visible in the filesystem as separate copies of
the repository, so you can manage/view/browse/script them just like
any other directory or file.

- a


"Neill A" <> writes:
> I've just started looking into getting our VHDL code into some sort of
> version control tool, and would like to get some information about
> which ones work best with VHDL & FPGA tools.
>
> All our designs are done using Actel Libero, and AFAIK it doesn't
> provide any helpful features for version control. I have previously
> used SourceSafe for a little while, but since we are just a small
> company I think the cost is a bit much.
>
> Our software team currently use PVCS, has anyone had any experience
> using this with VHDL?
>

--
PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380

Adam Megacz

Neill A wrote:
> I've just started looking into getting our VHDL code into some sort of
> version control tool, and would like to get some information about
> which ones work best with VHDL & FPGA tools.

If you set up your directory structures with some thought, and you use
Makefiles and shell scripts to do the builds, your files will all be
text and basically any version-control system will be fine.

Don't expect any of the FPGA vendors to add SCC hooks into their
software.

> All our designs are done using Actel Libero, and AFAIK it doesn't
> provide any helpful features for version control. I have previously
> used SourceSafe for a little while, but since we are just a small
> company I think the cost is a bit much.

I use Subversion (http://subversion.tigris.org/). It's free, it's
well-supported, and unlike VSS, it doesn't suck (or eat your
repository). There's an excellent Windows Explorer shell tool called
TortoiseSVN (http://tortoisesvn.tigris.org/) that puts useful icon
overlays on all files that are under version control, as well as adding
context-menu commands. Recommended.

-a

Andy Peters

Neil,

We use PVCS for version control with our VHDL, and it works just fine. The
only tricky part is figuring out what files (beyond the vhdl) that your tool
really needs to recreate a particular version, such as constraints, cores,
and project setting files. Since we use 3 different tools (Active-HDL /
Synplicity / Xilinix ISE), it took a while to figure out which files store
which configuration information to truly recreate a project from pvcs. I
would recommend creating the pvcs project folders to exactly mirror your
fpga working folder structure.

-Paul
QuadTech


"Neill A" <> wrote in message
news: oups.com...
> I've just started looking into getting our VHDL code into some sort of
> version control tool, and would like to get some information about
> which ones work best with VHDL & FPGA tools.
>
> All our designs are done using Actel Libero, and AFAIK it doesn't
> provide any helpful features for version control. I have previously
> used SourceSafe for a little while, but since we are just a small
> company I think the cost is a bit much.
>
> Our software team currently use PVCS, has anyone had any experience
> using this with VHDL?
>

Paul

Paul wrote:
> Neil,
>
> We use PVCS for version control with our VHDL, and it works just fine. The
> only tricky part is figuring out what files (beyond the vhdl) that your tool
> really needs to recreate a particular version, such as constraints, cores,
> and project setting files. Since we use 3 different tools (Active-HDL /
> Synplicity / Xilinix ISE), it took a while to figure out which files store
> which configuration information to truly recreate a project from pvcs. I
> would recommend creating the pvcs project folders to exactly mirror your
> fpga working folder structure.
>
> -Paul
> QuadTech
>
Can you tell us a little more? I am just starting a big new FPGA
project, using the same set of tools, in a company which doesn't
have a methodology for FPGA version control.

How can you save a project in a way that a "get all" command prepares
the entire environment? I'd like to be able to get all project files
to any random root folder and be able to work immediately.

I've already seen some problems:
* ISE, Synplicity and Active-HDL have their own project files; if
the source-files are not in the tool's project folder-tree, the
project file records the absolute path to the file. How do you
change your project/version root-folder without manually enering
all files again in all tools?
* CoreGen creates net-lists in its own folders; you have to
manually copy them to the ISE root folder.

assaf_sarfati@yahoo.com

We are able to fetch an entire project from pvcs into any root folder &
rebuild the project, by setting up our working folders & matching pvcs
folders. We let Active-HDL put stuff where it wants to. Synplicity can be
setup to use relative paths (for example ..\src\Subsystem1) in its project
file. Xilinx ISE 7.1 can use relative paths to reference the Synplify .edf
file (..\Synplify\rev_1\foo.edf). The xilinx cores .xco & .edn must be in
the Xilinx folder. Note that if you're using any Xilinx symbols within
Active-HDL block diagrams, ISE must be setup to search the appropriate vlib
folder from the Active-HDL install folder. Assuming you're using just the
working library, a structure might look like this:

MyWorkspace (MyWorkspace.aws)
+-MyDesign (MyDesign.adf, MyDesign.lib, fsm.set, bde.set, compilation.order)
+-compile (vhdl generated from .bde & .asf)
+-src (your vhdl code)
+-Subsystem1
+-Subsystem2
+-XilinxCores (.vhd files from CoreGen)
+-Synplify (Synplify .prj & .sdc files)
+-Xilinx (Xilinx .ise, .ucf, .ipf file, along with .xco & .edn files
from CoreGen)

Hope this helps.
-Paul

<> wrote in message
news: ups.com...
> Paul wrote:
>> Neil,
>>
>> We use PVCS for version control with our VHDL, and it works just fine.
>> The
>> only tricky part is figuring out what files (beyond the vhdl) that your
>> tool
>> really needs to recreate a particular version, such as constraints,
>> cores,
>> and project setting files. Since we use 3 different tools (Active-HDL /
>> Synplicity / Xilinix ISE), it took a while to figure out which files
>> store
>> which configuration information to truly recreate a project from pvcs. I
>> would recommend creating the pvcs project folders to exactly mirror your
>> fpga working folder structure.
>>
>> -Paul
>> QuadTech
>>
> Can you tell us a little more? I am just starting a big new FPGA
> project, using the same set of tools, in a company which doesn't
> have a methodology for FPGA version control.
>
> How can you save a project in a way that a "get all" command prepares
> the entire environment? I'd like to be able to get all project files
> to any random root folder and be able to work immediately.
>
> I've already seen some problems:
> * ISE, Synplicity and Active-HDL have their own project files; if
> the source-files are not in the tool's project folder-tree, the
> project file records the absolute path to the file. How do you
> change your project/version root-folder without manually enering
> all files again in all tools?
> * CoreGen creates net-lists in its own folders; you have to
> manually copy them to the ISE root folder.
>

Paul

I agree with Andy Peters.

My company uses subversion (SVN) for all development. I recommend it
highly. The server and clients can be installed on nix and windows
(maybe others?). It has the ability to handle tags and branching.
Merging is very simple using the Tortoise SVN client gui.

I think SVN beats all the other options to a pulp. It is insanely easy
to setup basic functionality too.

Brandon

wrote:
> Paul wrote:
> > Neil,
> >
> > We use PVCS for version control with our VHDL, and it works just fine. The
> > only tricky part is figuring out what files (beyond the vhdl) that your tool
> > really needs to recreate a particular version, such as constraints, cores,
> > and project setting files. Since we use 3 different tools (Active-HDL /
> > Synplicity / Xilinix ISE), it took a while to figure out which files store
> > which configuration information to truly recreate a project from pvcs. I
> > would recommend creating the pvcs project folders to exactly mirror your
> > fpga working folder structure.
> >
> > -Paul
> > QuadTech
> >
> Can you tell us a little more? I am just starting a big new FPGA
> project, using the same set of tools, in a company which doesn't
> have a methodology for FPGA version control.
>
> How can you save a project in a way that a "get all" command prepares
> the entire environment? I'd like to be able to get all project files
> to any random root folder and be able to work immediately.

You have to be smart about how you create your projects in the first
place.

> I've already seen some problems:
> * ISE, Synplicity and Active-HDL have their own project files; if
> the source-files are not in the tool's project folder-tree, the
> project file records the absolute path to the file. How do you
> change your project/version root-folder without manually enering
> all files again in all tools?

Certainly in ModelSim and ISE, you can specify relative paths as you
add files to the project. Sometimes I forget and have to manually edit
the ModelSim project file to make the paths to the sources relative.
Once it's done, though, it sticks.

Active-HDL sorta drove me bonkers, as it has its own way of organizing
things and I never did figure out how to convince it to use my
particular source tree format.

Here's how I set up my projects:

projroot\
\src\ top level for synthesizable source code
\moduleA some convenient synthesizable module
\moduleB another module
\testbench\ test bench sources, project file, scripts
\modelA behavioral testbench model (an SRAM, perhaps)
\modelB another simulation model (PCI core, maybe)
\fitter\ FPGA constraint, project, build, Makefiles
\synth\ synthesis-tool scripts, project etc files
\docs\ READMEs, theory, explanations, requirements,
etc

Some points:

The src directory and its subdirectories contain only synthesizable
sources.

Both moduleX and modelX are entities that are shared among many
designs. (My nomenclature is that a "module" is synthesizable code you
put in a chip, whereas a "model" is a behavioral simulation model.)
They're in their own subdirectories because they are added to the
design using Subversion's externals properties. In other words,
they're not part of the chip project's trunk/branch, but rather they're
other "projects" (in the repository) unto themselves. (The smart
developer externals a read-only tag for these modules/models; this way
if you build a chip using version "A" of a module and someone comes
along and updates it to version "B," you don't get the wrong files,
especially if you need to go back to an older design and check out the
sources used to make it.)

I keep all testbench VHDL sources, .do files, simulation Makefiles and
project files in the testbench directory. These are kept in version
control. Temporary files, .WLF files and the work directory are not
kept in version control, for obvious reasons.

The fitter directory is where FPGA fitter/P+R tool scripts, constraint,
project and Makefiles are kept. Most of the tools have improved such
that they handle relative paths well and anything that copies a source
file to the fitter directory is BROKEN. Obviously, the tools spit out
a lot of temporary files and report files and create "work"
directories. All you need to keep in the version control repository is
the stuff needed to actually build the chip: constraint files, source
list files, etc. Buried somewhere in the tool documentation should be
a list of the various files used and created by the tool. I do NOT
normally keep final build results (.bit, .mcs, whatever) in the
development trunk.

Now, when it comes time to release something, you "tag" it. In
Subversion, this is simply a cheap copy, so it doesn't cost any disk
space. My repo is set up such that tags, once created, are read-only
(tags can't be modified). What I do is to add (literally "svn add")
the fitter build results (.bit, .mcs, whatever is used to actually
program the parts) to the trunk, do an "svn copy" to create the tag
from my working copy, then "svn revert" to remove the build results
from source control in the working copy (it doesn't delete the files
but it removes them from revision control).

I should point out that Makefiles (I build under Cygwin) are a G-dsend,
although I tend to live in the GUI until I'm sure things are meeting
timing.

So the great thing about all of this is that I can check out a whole
design by doing, say:

svn checkout svn://svnserver/repos/projA/trunk .

and it grabs everything required to simulate and build the current
development version of projA and stuffs it into the current directory.

I've found it convenient to have a "skeleton" project in the
repository. The skeleton has all of the directories already set up.
You simply do a copy on the repository:

svn copy svn://svnserver/repos/skel svn://svnserver/repos/projB

to create a new "project" within the repository. You then check out
projB and work as usual.

> * CoreGen creates net-lists in its own folders; you have to
> manually copy them to the ISE root folder.

CoreGen is stupid in that regard. When I use it, I create the CoreGen
project in a temporary directory, extract the files needed, and copy
them to the source directory. If I know that I am going to reuse that
Core, I simply put it into the repository as its own project, and add
it to a chip's source as an external. For example, I have the
PicoBlaze processor source in the repository as its own project.

-a

Andy Peters

Brandon wrote:
> I think SVN beats all the other options to a pulp. It is insanely easy
> to setup basic functionality too.

I'm a software engineer and I have selected Subversion for my company's
development.

One thing Subversion has over some other free tools is that it does
directory versioning. This is a good thing(tm).

Paul Marciano

Andy Peters wrote:
>
> Certainly in ModelSim and ISE, you can specify relative paths as you
> add files to the project. Sometimes I forget and have to manually edit
> the ModelSim project file to make the paths to the sources relative.
> Once it's done, though, it sticks.
>

Versions of ISE through 6.3 handled relative paths quite well. And the
project file was plain text, another handy thing for making sure what
was going on and making changes.

With ISE 7.1, I no longer seem to be able to use relative paths. If you
know how to, please let me know! And some bonehead decided to make the
project file into some binary format. Arggh!

Duane Clark