Mail Archives: geda-user/2015/12/30/00:27:12
On Tue, 29 Dec 2015, John Doty wrote:
>>
>> 1. PCB exports a set of commands (I call it a patch)
>
> An interface. Good. Is it documented?
>
Yup. The documentation preceded implementation. I even shared the doc for
RFC back in August.
http://repo.hu/projects/pcb-rnd/devlog/20150830b_back_ann.html
There are some real minor changes in the syntgax after the implementation,
but the concept did not change.
>>
>> 2. gschem loads the patch and provides a "search" function that assist the user to manually change the schematics so that it doesn't contradict the patch
>>
>> I quickly abandoned trying to go with netlists, because I wanted to back annotate attribute changes as well (such as footprint changes). The patch says things like:
>>
>> - "pin 1 of U4 should not be connected to net Vcc"
>>
>> - "pin 1 of U4 should be connected to net Gnd"
>>
>> - "the value of footprint attribute of U4 should be dip(8)"
>>
>> So the "search" functionality in gschem is really searching for items on the patch that do not match the features of schematics currently open.
>>
>> Disclaimers for John (because I know he will repeat his agenda anyway):
>>
>> - I fully undrerstand your way of manual diffing, but I do not like it; if I already use a GUI for editing the schematics, I do want the GUI to assist me with the changes.
>
> OK. Perhaps a tool could generate your patch from the diff.
Or from anything else. In pcb-rnd, the patch is not genreated by
maintained. This means once I explain pcb-rnd that I want to swap two pins
or change a footprint, it does understand my intention and it does know
that it's an explicit, intentional deviation from the original design.
This info is saved an loaded. If a forward annotation fixes some of the
deviations, they cease to be deviations.
>
> I note that when I did this recently for a fairly drastically revised layout I expected it to be harder than it turned out to be. The layout guy had condensed a microcontroller and an FPGA into one thing, with the associated changes in support fungus, and a couple of other changes he hadn?t mentioned (but his netlist revealed). The lack of GUI support was a concern. But doing it from the diff was was easier than I expected.
I note that I did this often in the past. Manually. Using different sort
of manual or semi-manual methods to carry the info from PCB (or wherever
the change was made) to gschem. I learned this way that I wanted a GUI for
this.
>>
>> - the method is generic, not limit to the PCB flow or any specific flow; in any flow the user can produce such patches; like tuning resistor values after simulation
>
> Layout tools can often generate an output netlist and BOM, but few will be able to directly generate your patch file. So, some way to get from those to your patch file are required to make this truly generic.
Native support is only an option. The layout tool may generate whatever it
can and an external tool can generate the patch.
In pcb-rnd I have native support because I find it essential to be able
to keep track on the explicit changes. Without this: if I swap 2 pins,
pcb makes this change only in its copy of the netlist, then I forget to
back annotate then forward annotate again... I'd get the 2 pins swapped
back. pcb-rnd wouldn't be able to decide if the local copy of the netlist
had my intentional change or not.
> A common netlist/bom format with a canonical form (so equivalent
> netlists would be identical) would be a useful intermediate.
Could work. To me, the current patch format is much cleaner. I already
have fully working code both in pcb-rnd and gschem. If you implement an
alternative solution that is at least as capable, let me know.
>>
>> Also, John, you are confusing two things. One thing is a generic C function that can list all direct connections of an object. This can not "get in your way more often than it helps" because you never get to see it as an user.
>
> Why are you not using the Scheme scripting that Peter Brett worked so hard to make useful?
I tried. Was not so useful for me. We disagree on whether scheme should be
used (at all). Let's not rehash this.
>>
>> The other thing is what exactly happens when you click on a net.
>
> The overloading of that is a problem in the current GUI.
And this has nothing to do with our topic.
>> I am an user of gschem. Whatever flows you use, whatever flows I use, please do not try to convince me that I don't need to locate a network by name in my design.
>
> All the work that Peter did was intended to help users like you and me make our own customizations to gschem and publish them without stepping on each other. So, why are you not exploiting this?
It was intended so. But did not work so. It's surely my fault and all the
other folks' faults who did not write scheme scripts. I say this after I
did invest time in trying to do something simple in gnetlist in scheme.
Much simpler than this task. Took irreal amount of time, didn't end up any
better than if I had written it in C. Before someone says how gnetlist
differs from gschem: long before that I did changes to some scheme scripts
in a totally idfferent project - with the same conclusion. Scheme is not
for me, that's all.
In my case there were two options: sit down and make it work (which means
C) or sit down, waste weeks and eventually give up (scheme).
I also think having scheme in libgeda and gschem core is a wrong decision.
If I imlement a feature in my fork, I will do it in a way I find best -
which means removing, not adding scheme.
Also note: only a fraction of the code I produced are new features,
and only a small fraction could be in scheme. A big part of the effort was
to work around the non-generic search implementation - which is all in C.
Using scheme wouldn't have changed that the bigger part of the patch has
to be in C.
- Raw text -