Project files management (was Re: Welcome)

[Lothar Behrens]

Am 20.04.2009 um 20:50 schrieb Werner Almesberger:

> Lothar Behrens wrote:
>>> One advantage of using a text-based format for EDA-specific files
>>> would be that SVN and friends wouldn't choke on them :-)
>>
>> At least netlists and BOM's could be used to figure out differences.
>> If source code is available, even patching netlists would be a way -
>> with an additional step of placing
>> new components on the sheet manually.
>
> I was just thinking of what sort of mess it would leave in the
> SCM. If the files are text, the effect of most changes would be
> relatively small and wouldn't put an undue burden on the SCM.
>

Heh they are propably commitable as text files, but not tested I  
think :-)


>> It was about sorting the nets and the parts and pint out which parts
>> then are on different nets. It saved the project :-)
>
> Heh :-) Such a script to compare two netlists for equivalence
> would indeed be useful. E.g., when someone sends a patch you
> can't or don't want to apply automatically, you could still
> verify that, in the end, all the manual changes yield the same
> result.
>

It was a concrete application using MFC classes, but console only.

> That would be similar to "diff without the whitespace changes."
>
> But also a way to compare two files for identity and to highlight
> the changes would be useful.
>

That was it for, highlight the nets and components, that were  
different, missing on left / right and the like.
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.

The result was the pain that there was no way to compare.

>> Using an half look through layer for two versions would be a way :-)
>> Also helpful would be a visual 'offset' to ease spotting of small
>> differences.
>
> Hmm, four layers perhaps ? Layer "before", layer "after", layer
> "removed" (present in "before" but no identical copy exists in
> "after"), and one layer "added". If one could toggle layers from
> color to grey/invisible, that should be sufficient for visually
> finding all the changes. If items in each layer can be deleted,
> it would even be possible to check off the changes one by one.
> Add an "items in this layer" count to know when you're done.
>

I also mean the schematic to be compared by a visual compare with an  
overblending of the old compared to the new.
Using an offset also helps finding removed or added parts, because  
there are missing these doubly painted sysmbols.

It is like you unfocus on the picture, you will see it doubly :-)

>> KICAD supports subsheets, so these may be 'modules'.
>
> And they go into separate files already. Cool, problem solved :-)
>
>> Using a virtual PCB ontop of another PCB may also be a module.
>> (System on a module, but board would be the same at the end)
>
> That would new code, right ? In general, I find that KiCad lacks
> the ability to merge "boards" into larger structures, e.g., to
> make panels. By introducing an object that is a - possibly
> recursive - "live" reference, we could have something that serves
> both purposes.
>
> Properly separating the netlists would be a little harder, but
> then, if one runs the DRC only at the level where everything
> should come together, that's probably good enough to get started.
> (You'd see other people's mistakes, but that's not so different
> from compiling programs ;-)
>
> Getting new items from the netlist would be messy if we don't
> have a means to separate netlists. But perhaps solving that can
> be deferred until a "phase two", and one would either add new
> things manually or get the whole rabble, pick the one one really
> wants, and delete the rest. Some sort of external tool could also
> help.
>
>> The KICAD sch and brd files are at least plain text. But it will be
>> hard to 'understand' the differences if you are
>> not a 'crack' or a KICAD programmer. (I am not that crack :-)
>
> Yeah, I think some visual helps are indispensable for normal
> work. But it's good to have an easy access to the internals if
> necessary.
>
>> The Lines do not seem having an ID that also is used in 'connections'
>> from line to pin.
>
> That would again be needed for a test for equivalence. A visual
> comprison could do without it.
>
>> It would be better, if the EDA tool stores the 'project' in a
>> database. Then a team could work on the same a little better.
>
> Hmm, I'm somewhat sceptical about the concept of "joint editing".
> I think distributed editing with tools that help to merge the
> result would go a long way. You can do the "locking" on IRC :-)
>
> Instead of a patch, you would just send the resulting file in one
> way or another. That's the fallback mode for code as well, if
> someone sends you something cryptic that doesn't seem to fit
> anywhere. Bandwidth is cheap :-)
>
> So ... seems that all that's needed to make KiCad better for
> collaborative development would be:
>
> - a "diff" mode for eeschema and pcbnew that shows the content of
>  two files in four views ("a", "b", "a-b", and "b-a"), with ERC,
>  netlists, etc., only being done on either the current view or
>  just "b".
>
> - a new object for pcbnew that acts as a "live link" for other
>  .brd files and just merges whatever is in them into the current
>  board, with the appropriate offset.
>
> Still looks feasible ;-)
>

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.

Another idea would be logging the changes - writing the undo stack to  
the database and keep version before linked
with the undo stack against the new version, thus you have a  
transaction log from version to version.

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?

BTW I have posted a question about success stories using KICAD for  
high integration projects (using FBGA howsings).
http://tech.groups.yahoo.com/group/kicad-users/

The topic is 'KICAD success stories ?' and it would be interesting.  
One told me they are using SVN. One is about up to 1.3 GHz frequencies
in a Vector analyser.

But untill now only up to 6 layers. So I'll look forward and wait :-)

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?

It doesn't need to be ready for real usage, but to see if the  
development cycle up to a prototyping firm could be done.

Beside of all this stuff: Is there an option for an FPGA to add custom  
logic to the phone?
There are Linux based prototyping boards that are having / based on  
FPGA chips. Except the size of these chips I saw, if they are  
available as
smaller versions, they may fit into the phone. This is nothing for the  
mass market, but for custom appliances in the industry :-)

Stupid idea, right? :-)

Lothar

> - Werner
>

-- | Rapid Prototyping | XSLT Codegeneration | http://www.lollisoft.de
Lothar Behrens
Heinrich-Scheufelen-Platz 2
73252 Lenningen