Version Control Software

[Neill A]

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?

 

[Adam Megacz]

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" <neilla@ewst.co.uk> 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

 

[Andy Peters]

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

 

[Paul]

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" <neilla@ewst.co.uk> wrote in message
news:1126861259.461630.193380@g44g2000cwa.googlegroups.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 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]

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

<assaf_sarfati@yahoo.com> wrote in message
news:1127883427.597511.41890@g47g2000cwa.googlegroups.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.

 

[Brandon]

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.

 

[Andy Peters]

assaf_sarfati@yahoo.com 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

 

[Paul Marciano]

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).

 

[Duane Clark]

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!

 

[David Brown]

Brandon wrote:

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.

We too will be moving to Subversion sooner or later. Out of curiosity,
do you use separate repositories for different projects, or do you have
them all in one? And how do you access the server locally (svn or http
protocol)? There are several options when setting up Subversion, so I'm
trying to figure out which would make most sense from the start.

 

[Brandon]

We typically create a new repository for different projects so that
only certain individuals have access to certain projects, since someone
could very well delete files from a head revision. We also have a
'sandbox' repository that everyone has access to for testing and such.

We use http. Our SVN server is installed on a dedicated linux box,
although it was originally installed on an coworker's workstation when
we first started out. I also know it's possible with http to setup a
vpn connection to a SVN server, but we've yet to convince our uptight
IT ppl that it would not be a security compromise.

 

[David Brown]

Brandon wrote:

We typically create a new repository for different projects so that
only certain individuals have access to certain projects, since someone
could very well delete files from a head revision. We also have a
'sandbox' repository that everyone has access to for testing and such.

We use http. Our SVN server is installed on a dedicated linux box,
although it was originally installed on an coworker's workstation when
we first started out. I also know it's possible with http to setup a
vpn connection to a SVN server, but we've yet to convince our uptight
IT ppl that it would not be a security compromise.

I have been thinking along the same lines. For the most part, all our
developers will have access to everything (we are a small group) - if
someone deletes something by mistake, it can always be "undeleted"
(that's part of the point of a revision control system!). I also plan
to allow https access from certain home machines (saves any need for a
vpn), and maybe even occasional customers for colabaration projects.

Do you find that subversion works well for binary files too (obviously
without differencing and merging), like object code or pcb design files?

mvh.,

David

 

[Andy Peters]

Duane Clark wrote:

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!

Dunno -- it just works. If you're creating a project with existing
sources, make sure that you don't check the "copy to project" option
when adding them to the new project.

I just did a quick test. I created a new project without adding
sources. I then chose the "add existing source" option. I added some
sources that are on the same disk drive as the project, and those were
added using relative paths. I then added a couple of files that were
on a different drive, and those were added using absolute paths. Of
course, this is a Windows machine -- maybe if you were on Linux or
Solaris, this wouldn't be an issue (no frickin' drive letters).

If that's not the case, then, well, complain to Xilinx!

And some bonehead decided to make the
project file into some binary format. Arggh!

It's not completely binary; you can open it in a text editor. It does
have binary cruft in the beginning, but scroll down and you can see
your sources and such listed.

But I agree: configuration and project files should always be simple
plain text -- no XML, no binary, just good old-fashioned text. And it
would be nice if automated tools didn't totally reorder things in those
text files. diff is your friend, so make diff's life easier!

Tools vendors should strive to make their products revision-control
friendly. By that I DON'T mean adding support for Microsoft Visual
Source Safe. VSS is not an acceptable revision-control system.

-a

 

[Andy Peters]

David Brown wrote:

I have been thinking along the same lines. For the most part, all our
developers will have access to everything (we are a small group) - if
someone deletes something by mistake, it can always be "undeleted"
(that's part of the point of a revision control system!). I also plan
to allow https access from certain home machines (saves any need for a
vpn), and maybe even occasional customers for colabaration projects.

One cool feature is that you can give different users different
permissions. For example, customers can be given read-only access to
the repository, so they can't check things in.

Do you find that subversion works well for binary files too (obviously
without differencing and merging), like object code or pcb design files?

It works quite well for binary files. You just have to be real good
with comments. Things like "checked in newest version" doesn't tell
you anything if you can't diff the files.

-a

 

Andy Peters wrote:

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

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.

I've looked into Active-HDL project file (.ADF) and it appears to be a
simple text, with all files recorded TWICE (files and files.data) - who
knows why? I'll try playing with it and see what happens.

There is also the compilation-order file, surprisingly called
compilation.order. The file-paths in it are already relative.

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.

I didn't try creating the tools' folders below the project-root,
because most tools create an amazing number of junk files.

--- SNIP ---

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.

I am using the ISE Project Nav GUI; not very user-friendly, but
I can't be bothered to create "scripts" (actually batch files) to
run the P&R tools from the command-line (been there, done that).

ProjNav (ISE 7.1) has a (sort of) BINARY project file (.ISE).
It also has a nasty "feature": if you use the "add source"
command from the Modules tag, it adds a link to the file; if you
use the same command from the Library Modules tab, it copies the
file to the ISE folder.

What were they thinking of? If a command is called the same,
it should behave the same. I also HATE binary configuration
files; they don't allow me to play around with things the S/W
should have, but didn't, allow to to do via UI.

Well, it could have been worse; they could have kept everything
in the Registry, the way most Windows programs do today (and
I'd like to shoot the guy who invented the Repository - same
idiot mentality as "throw it in the garage, we'll find it
there later).

--- SNIP ---

* 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

CoreGen project files are also text, and also appear to contain
absolute paths; I'll play with these as well.

You still have to copy the generated net-list (EDIF or NGD) to the ISE
root-folder. I don't like calling tools from the Proj-Nav; I'd rather
use each tool as stand-alone.

Synplicity's project files are actually TCL scripts; shouldn't be a
problem to use relative paths.

A final problem: if I keep each tool's folder-tree as separate
sub-folders below the project's root, I still have to copy
intermediate files manually (synthesis and coregen net-lists);
maybe I'll just add a batch file to do it and keep it as part of the
project.

I guess that I can't create an environment where a know-nothing
user can get a project and just hit a button to build everything;
unlike software projects (where the whole project is often built
by non-programmers such as QA people), an FPGA project must be
built by someone who knows at least a little about the tools.

-- Assaf Sarfati

 

[Duane Clark]

Andy Peters wrote:

Duane Clark wrote:
...
With ISE 7.1, I no longer seem to be able to use relative paths. If you
know how to, please let me know!

Dunno -- it just works. If you're creating a project with existing
sources, make sure that you don't check the "copy to project" option
when adding them to the new project.

I just did a quick test. I created a new project without adding
sources. I then chose the "add existing source" option. I added some
sources that are on the same disk drive as the project, and those were
added using relative paths.

That is the way it always worked for me before. But not now :-(

I then added a couple of files that were
on a different drive, and those were added using absolute paths. Of
course, this is a Windows machine -- maybe if you were on Linux or
Solaris, this wouldn't be an issue (no frickin' drive letters).

I'm on Linux. Perhaps they added that as a "feature" just for us

If that's not the case, then, well, complain to Xilinx!

If it is working right on Windows, then indeed I think I'll complain.