Mail Archives: geda-user/2015/07/07/23:52:27
On Tue, 7 Jul 2015, Ouabache Designworks (z3qmtr45 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
>
>
>On Tue, Jul 7, 2015 at 9:05 AM, Evan Foss (evanfoss AT gmail DOT com) [via
>geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>
>
> The Unix mentality these are all independent tools that we
> choose to
> combined this way. Most people have avoided binding them via a
> database because they want to keep things separate.
>
>
>Works great as long as the data in the pipes only flows in one direction.
>What do you do when you need to backannotate from one tool to another?
It's not because pipes have to be unidirectional. It's because the actual
toolchain lacks the backannotation path. That path can be implemented in a
path-independent way. This does not depend on having separate tools at
all; actually back annotation is a great example to demonstrate this, so
let's take a closer look.
There are multiple ways doing forward annotation; what I do is I run make
to get new stuff from gschem to pcb. PCB GUI is perpared for
loading a new netlist or new components and the glue can prepare data in a
way pcb is happy with. An important aspect is that PCB defines
"completeness" (rat lines) so after receiving the new info, it can
clearly show the user what needs to be done so that the PCB macthes the
_current state of the design_.
But what's the current state of the design? Because we have forward
annotation-only, currently anything the schematics say, and anyone else
has to follow the changes on the schematics.
Technically the very same thing could work in the other direction as well:
I make my modifications in PCB and use external glue to get them back to
gschem. Then the current design is a bit more distributed and depends on
where the user made their last modifications. What's needed for this and
we don't have {what keeps me back from coding it myself}:
1. solve the lack of gschem's idea of "completeness"; sort of rat lines -
so when I swap connector or GPIO pins on the PCB, gschem would know the
connections on the schematics are incorrect, would indicate so and the
user could update the schematics to match the design {scheme}
2. A way gschem could load such information from an external source (e.g.
files, like PCB does with the netlist) {scheme}.
3. PCB features so that the user can tell PCB that a specific a
difference/deviation/change in a netlist/footprint/whatever is intended
and should be back annotated {that point 1. and 2. wouldn't be done}.
4. A glue script in PCB -> gschem direction; it'd probably read the PCB
file that'd have changes of point 3 marked and would generate the file
required by point 2 {that point 1. and 2. wouldn't be done}.
Back to your original statement on UNIX mentality: imagine we had an
integrated tool. It would include gschem and PCB and gnetlist, as one
monolithic GUI, maybe even written in the same language, but each with
its current design. It would be something equivalent with the current
code base, feature-wise. Alternatively imagine you can easily combine
them into such a monolith with a magic wand.
In either case, exactly which points we wouldn't need to solve of the
above 4? The only diff I can think of is point 4., which we would still
need to solve, of course, just it wouldn't be an external script but some
internal code. Thus I don't see how tighter integration would save any
work on back annotations.
Regards,
Igor2
- Raw text -