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?
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.
formatting link
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.
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.
I use Subversion
formatting link
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
formatting link
that puts useful icon overlays on all files that are under version control, as well as adding context-menu commands. Recommended.
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.
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.
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)
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.
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.
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:
to create a new "project" within the repository. You then check out projB and work as usual.
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.
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!
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.
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?
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!
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.
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.
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.
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.
I didn't try creating the tools' folders below the project-root, because most tools create an amazing number of junk files.
--- SNIP ---
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 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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.