Using Subversion for both hardware and software versioning

[Stephen Turner <sg...@audioscience.com>]

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.

thanks
------------------------
Stephen Turner
AudioScience, Inc.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Using Subversion for both hardware and software versioning

[kf...@collab.net]

Stephen, please see

   http://subversion.tigris.org/mailing-list-guidelines.html#fresh-post

...about how to avoid accidentally joining unrelated threads.

Thanks,
-Karl

"Stephen Turner" <sg...@audioscience.com> writes:
> 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.
> 
> thanks
> ------------------------
> Stephen Turner
> AudioScience, Inc.
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Using Subversion for both hardware and software versioning

[Andy Peters <de...@latke.net>]

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