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