Stephen Turner wrote:
> We are currently using CVS for our sw versioning.
>
> We'd also like to put our hardware projects (schematics, FPGA code etc)
> under version control. The schematic files are binary - one reason why CVS
> is nota good choice.
>
> So, we are thinking of putting everything under Subversion.
>
> Question - should everything (h/w and s/w) be in one repository - i.e have
> one global version?. Our development dir tree looks something like this:
>
> base
> --hw
> --project1
> --project2
> .....
> --projectN
> --sw
> --applications
> --project1
> --project2
> .....
> --projectN
> --drivers
> --project1
> --project2
> .....
> --projectN
> --firmware
> --project1
> --project2
> .....
> --projectN
>
> We were thinking that maybe we should have one repository for h/w and one
> for s/w, but would like to hear from other users who are using Subversion in
> a similar scope.
(Before I start: I consider a "Tag" to be a read-only snapshot of the
design. Tagged files are used by production to build things, or are
otherwise considered non-modifyable.)
I'm a hardware guy, but of course "hardware" these days includes FPGAs
(designed using HDLs) and microcontroller and DSP firmware. I've gone
back and forth on how to organize things. The original idea was to
organize by project, and within each project is a folder for schematic
and PCB design (including BOMs and Gerbers), a folder for each FPGA, a
folder for micro or DSP firmware. The idea being that you could check
out the top level and get the whole picture.
But then things got complex. An obvious example is where one FPGA
design may be used on more than one board. (Make it more complex --
same code, different pin-out or device!) Or, a PCB gets built and there
are updates/fixes or just different versions of firmware or FPGA loads.
It became clear that the repository really had to be organized by "type"
-- like you describe, there's a folder called "fpga," a folder called
"firmware," a folder called "PCB," a folder called "host app," a folder
called "driver," and so forth, and under each are the specific projects.
Under "fpga," each project has a "src" folder where I keep all of the
synthesizable sources, a "fitter" folder where I keep FPGA synthesis and
place-and-route tool project and constraint files, and a "testbench"
folder where I keep the non-synthesizable test bench code.
Under "fpga," in addition to each project, I have a folder called
"models," which contains behavioral (non-synthesizable) HDL models of
various things that I use in my test benches. There's also a folder
called "modules," which has synthesizable "cores" that are usable across
multiple designs. These models and modules are included as necessary
using externals properties. Ideally, you'd create and verify the
modules and models and tag the "known good ones," and use the tagged
versions in the design. This way, if/when you update a module or model,
you don't break designs that use the older versions. (This should all be
completely obvious to software guys who reuse code all the time.) You
don't want to start a debug session by checking out a tagged FPGA
release and have it pull a newer version of your SPI module -- one
that's not what you actually burned into the FPGA!
You'll have to come up with a higher-level schema (outside of version
control) that relates specific designs (firmware/PCB/FPGA) to products,
but you probably already have something like that in place.
You can use Subversion's externals property to make a "product" tree
under the respository root so you can check out a specific release of
"gizmo" and get all of the underlying stuff. For this to work, you'll
need to keep everything in the same repository.
Anything that gets built or released to a customer gets tagged. When
you fab a PCB, the schematic, PCB files and Gerbers get tagged. An FPGA
load given to production needs to be tagged. Usually, you don't keep
.bit/.jed/.pof/.mcs files during development, but since the FPGA tools
can and do vary their results even if the sources are unchanged, it's
important to include the files used to program the parts in your tags.
You get the idea.
Anyways, this is all the result of using Subversion for hardware designs
for the last couple of years. Now that Subversion lets you lock files,
you can check out binaries (like PCB files and the like), lock them, and
other users will know that they shouldn't change those files since they
can't be merged.
Now, if only the FPGA vendors would make their tools more source-code
control friendly, we'd be getting somewhere. As it is, they all seem to
default to dumping everything into one big directory and not being clear
as to which files are actually important and which are just temporaries!
-a
-------------------------------------------------------
Andy Peters
5511 E Rosewood St
Tucson, AZ 85711
520-907-2262
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Jun 21 08:59:34 2005