Hi,
I am working in a small business having 4 embedded systems engineers. We are currently using subversion for version control of the source codes. We want to use it also for the version control of our PCB designs. We are currently using Altium Designer and Circuit Studio for the PCB schematics and layout.

The goals we want to achieve are:

1) We want to create common component footprint database.

2) We want to work concurrently on the same project.

What is the best practice to achieve these goals? Is subversion OK for that? What kind of folder structure should we use?

Thanks in advance :)

-Yigit

We use Subversion for firmware and for PCB designs.

Since you already use svn for firmware, you know the workflow: each engineer uses a working copy of the project, and every time they start to work on the project they have to update their working copies and then commit the changes back to the repo. Working copies are not shared.

Altium Designer already has support for libraries stored in a Subversion repo -- they're the svndb libs. Each engineer checks out a working copy of the library and updates it as necessary.

As for designs, since svn (and other SCC programs) don't do binary diffs well, you should take advantage of svn's "lock" feature. All designs are of course working copies checked out from the repo. When someone wants to work on the design, they have to obtain the lock. This prevents someone else from committing a change while you are making changes. (subversion can't merge the binary files.) Once you commit your change back to the repo, the lock is released and another engineer can get the lock and make changes. So this really isn't "concurrent" design as such; it requires communication between the designers.

As for folder structure? The usual trunk/branches/tags works, although branching a PCB design as such doesn't make much sense because you can't merge the changes back to the trunk like you can with text files.

We use the tags folder for pre-releases and releases. A pre-release is something that we might wish to keep around for reference and redlining. Released means we sent it out for fab. 

Subversion will work - it can handle text and binary. I like the Windows Explorer add-on for ease of use.

You should have ONE person as the Footprint Release Ghod (FRG). ALL additions to your common footprint library should go thru them. They should get the new footprint && add it to the common location. ALL changes to a footprint goes thru the FRG.

Concurrent work on a specific project can be a nightmare. The issue is merging.

Think carefully about how you are concurrently working on a design. In general, a Good Practice is for ONE person to be responsible for a design. Anybody else working on the same project sends their changes to that person - call them Project Foo Ghod (PFG). The PFG is responsible for ALL merges. Hold a "Merge Meeting" - even informally - for each merge - basically an incremental design review.

It is good that you have a team that is working together. Each member needs to be responsible for a given project - and scaled pretty evenly - one has two/three small projects && one has a large project, or both have a large and small project. (Yes, you have 4 embedded engineers - just simplifying the description.)

I am assuming the engineers do the PCB layout - vs a dedicated layout person. The project ghod should be the one that does the layout - with a "layout design review" to catch the silly mistakes.

also, it is possible to get stuck on something - happens to everybody. Have a "trigger point" - like if something goes over a deadline - when the trigger occurs, the entire team concentrates on it.

I advocate the FIRST layout be on a single, flat board (or a couple of boards if there is a good connection point && the flat board is big..) Put in test points for ALL connections - where you have a hole to solder a male Berg header, and for busses, a connector you can plug a logic analyzer pod into. Makes it MUCH easier to write code && device drivers. You can put device drivers on a single board with your MPU to develop the drivers. Obviously, high speed stuff should be laid out as close to the final layout as possible, but those are rare cases. When possible, have the traces on the top layer to make them easy to cut.

(Use the Chinese board houses - they do a good job && you can get them to pick&place/easy-bake for a nominal cost. Or - use thru-hole for this level of development, or use a good tech to stuff the boards.)

If you are careful and clever about how you layout the schematic, you can put all test points on a separate sheet or two, and delete/ignore that sheet for the final layout.

I have done at least 100 device drivers. I will often use an Arduino as the "other side" - like if I am doing an RS232 driver, it will talk to an RS232 on the arduino. Or, I will use a simple sensor (eg temperature) on a breakout board from Sparkfun or Adafruit. I recently had a project with TI SRDES video link. It has an embedded I2C link. I put a temp sensor on the far end, and an I2C master on the near end. I was able to easily test the entire chain.

Do two spins on the flat board - the second should incorporate ALL changes && NOT need ANY blue wires. Take the first board, frame it, and put it on the wall. The second goes into an anti-static bag in a cabinet. Use it for the next-gen development.

After that, the only issues should be with the layout in the final form factor.

Hope this helps! ... bandit

Altium works great in version control tools such as SVN or Git. I have transitioned from SVN to Git some years back and have not regretted it.

All of the key Altium schematic/layout files are text and as such work really well with the version control toolchain. Have a common file for outjobs and a common file format for the whole project, so that a single checkout captures it consistently for everyone. I use a separate repository for parts and keep that as SQL using the .dbLink features Altium has, and assign an integration manager for the parts database. A pull request to the parts repo initiates the parts repo update if an engineer added/modified a part.

The other suggestions regarding having an integration manager are good, I do the same thing. Have an integration branch that people commit to, and the integrator pushes changes from that to the Master branch containing the definitive version of the hardware.