Project files management (was Re: Welcome)
werner at openmoko.org
Tue Apr 21 16:08:16 CEST 2009
Lothar Behrens wrote:
> The rest was hand made job to correct exactly that nets and parts. The
> problem happened because one
> has send a FAX !!! to communicate changes.
So much more discreet than a letter bomb but equally destructive ;-)
> Using an offset also helps finding removed or added parts, because
> there are missing these doubly painted sysmbols.
Okay, that would be spacial separation. I'd just go for temporal
separation, so you don't even need to modify any content.
> Usually experts state that CAD files or similar stuff has to be at
> least in BLOBS to speed up the loading
> of a sheet or board.
I'm sure that was a big concern in the days when tapes were almost
as fast as CPUs ;-)))
Naw, I don't think this is something we have to worry about in the
context of this project. It's not as if we would be modeling entire
airplanes down to the last bolt. Similar on the EDA side: people
seem to have tackled larger projects with KiCad just fine.
> What I mean with a central storage is the avoidance to post files
> around, because this leads to the following problem:
> What was the actual or correct file, I have four?
I'd go for having a file-level interface at KiCad (i.e., you pick
file X and compare with file Y) and then use SVN or git to keep
track of the files. That may not be perfect and certainly lacks
integration, but I think the underlying version control problem is
similar enough to what SVN and git are already used for.
> BTW I have posted a question about success stories using KICAD for
> high integration projects (using FBGA howsings).
Ah, saw that one ... and now I read it. Excellent, thanks !
> But untill now only up to 6 layers. So I'll look forward and wait :-)
One had 2 power planes plus 4 routing layers. That's not too bad. For
comparison, GTA02 has 8 copper layers (23 Gerber layers in total, but
that includes solder masks, drill files, etc.):
Top: almost entirely ground, a few traces around the upper and the
L2: a few dozen long-distance tracks, several of them looke like
power. About half the layer is just solid copper.
L3: ground plane with only a few very short traces
L4: routing layer, again mainly long traces, 40% "empty".
L5: ground plane, two traces :-)
L6: things are getting more busy around here. Mix of short and
long traces, about 70% occupancy, with the CPU/Glamo/memories
area quite saturated.
L7: similar to L6, slightly busier
Bottom: full of pads and a lot of small traces
So that's really five routing layers and three ground layers. Not
much worse than that six-layer board. (That's from looking at the
GTA02v5 Gerbers - I don't have PADS.)
I like Pedro Martin's reply even better:
| For example, Altera FPGA 484 pins BGA, 0.0060" Clearance, 0.0039 mask
| clearance, 6 layers, 0402 capacitors, through vias.
| All routings are hand made and boards are in production.
That's almost exactly what GTA02 is like. The CPU is a 332-FBGA, so
that's even easier ;-) And yes, I expected that the routing would
have to be done manually. So it's good to hear that it's feasible.
> What about creating the SOC 2442, NAND / NOR chips and related as a
> sample and try to create a small test project using 8 layers to create
> a prototyping board?
Yup, I'd go for what's in the main can, minus Glamo, minus NOR. That
leaves GPS, Calypso, BT, and WLAN out, but we're not interested in
modifying these at the moment anyway, and adding them later should be
> Beside of all this stuff: Is there an option for an FPGA to add custom
> logic to the phone?
Hmm, I'd make this a "later stage" feature ;-) Once we have the core
system, it should be relatively easy to spin off variants. The good
thing about variants is that not everyone has to agree on what goes
into them. So if your application requires a pair of XC2V8000 and a
small fan while mine needs an 8" floppy drive, that's alright ;-)
More information about the Gta03