Mail Archives: geda-user/2015/12/29/23:15:22
On Tue, 29 Dec 2015, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:
> On Tue, Dec 29, 2015 at 2:35 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>
>> On Dec 29, 2015, at 9:39 AM, Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
>>
>>> On Tue, Dec 29, 2015 at 3:46 AM, Nicklas Karlsson
>>> (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]
>>> <geda-user AT delorie DOT com> wrote:
>>>>> My personal opinion, especially after actually hacking the code for back
>>>>> annotation, is that there are design errors in the very core of gschem.
>>>>> A few smallish things that makes life harder in probably most flows,
>>>>> makes essential UI features impossible to implement. ...
>>>>
>>>> It would be good if you could bring the design erros forward.
>>>
>>> I think Igor2 already said of this in the last thread that he wanted
>>> to avoid saying because of the flamewar that would follow. I am a bit
>>> more rested so I will kick the bees nest in his place.
>>>
>>> gnetlist's one way functionality :
>>> gnetlist lets you take a schematic (which in libgeda world is a list
>>> of connections) and make a netlist but it won't let you take a netlist
>>> and map those nets back to connections on the schematic. PCB can be
>>> made to export a netlist. Ideally gnetlist would take a list of
>>> changes to a netlist or two netlists (old and back annotated) and spit
>>> out a list of changes to connections that you could carry over to
>>> gschem.
>>
>> I did this ad-hoc a few months ago with Osmond, and it wasn?t hard. The required tool is one that puts the netlist in a ?canonical? form, with connections sorted and assigned names of anonymous nets removed. Then, you just do an old-fashioned diff.
>>
>> One thing on my todo list is to make a gnetlist plugin that renames anonymous nets based on the first pin it sees in a sorted list of connections. This would give such nets stable names as long as their connections don?t change. This would be useful in a variety of flows, I think.
>
> Sorry, nothing will get me to adopt a flow that breaks manually named nets.
>
>>>
>>> nets vs connections:
>>> libgeda and gschem are only allowed to understand connections and even
>>> then in a limited way.
>>
>> Limits to the smarts of the tool are good. Make the tool understand too much and it gets in the way.
>
> We already talked about this. I am going to skip over it to avoid
> re-re-re-hash. (i did go back and check how many re's to use here)
>
>>> To make back annotation work you ether have to
>>> fix the problem above or let libgeda/gschem understand that a list of
>>> connections is associated to a given net in the netlist.
>>
>> You can?t imagine doing this with a specialized tool?
>
> The order of events to back notate.
>
> 1. PCB exports a netlist (which I will call the backward netlist)
> 2. diff of forward and backward netlists
> 3. gnetlist generates a list of changes to connections
> 4. gschem takes the changes and lets the user implement or disregard them.
>
> If that seems amilliar it is because this is mostly what Igor2 did.
> Igor2 had PCB run more of it but still.
Nope, my approach is totally different.
1. PCB exports a set of commands (I call it a patch)
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.
- 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
- I know that some parts could have been done by piping everything through
gnetlist backwards, but I simply don't see any benefit. No, the "toolit
vs. integrated" slogan does not work here (my current approach does not
integrate anything either).
- all parts are done in forks, so your Holy Workflow and Holy Version are
not affected by lame features noone would force you to use anyway.
(Although I strongly believe it's you who should make a fork and freeze
your Holy Version and leave others alone to go on fixing bugs and adding
missing features.)
>
> Why run so much through gnetlist? Because you won't let use endow
> libgeda with an understanding of netlists and to map the changes back
> the other way we need that.
With the format I use, we don't. My approahc has its limitations too, but
as I'll discuss later, these are rather the limitations of how gschem
doesn't want to know about nets, not even via the netlist infra.
>>> Right now
>>> gschem almost has this because there is a highlight functionality that
>>> lets you select a whole net and unintentionally maps the connections
>>> in the process.
>>
>> Functionality that gets in the way more often than it helps.
>
> You are right but the code is there and it works. (Igor2 proved it)
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.
The other thing is what exactly happens when you click on a net. It's a
GUI question, a decision, has nothing to do with libgeda. Or with the
topic we are discussing.
>>> I debated this one with John a while back. It was
>>> particularly hard to deal with because John fundamentally does not
>>> want back annotation/notation unless it is via some his script(s).
>>
>> Annotation is good and useful. Back annotation is problematic. Back in the early days of programming, assemblers used to back-annotate source code with the object code. That caused more problems than it solved.
>
> You just compared Apples to Asparagus.
A better comparison: I run a binary program that hits an assert() or
aborts and dumps core. Looking at the core and fixing the source is back
annotation. For this, I want the binary side tools (a debugger), and the
source code side tools (a text editor). The text editor needs a functions
like "jump to line N". For this, it needs to understand what a "line"
is. This makes it less general as if it didn't have to assume things like
special meaning of newlines, but such is life.
Gschem can not "jump to a network". For me, it is exactly the same as if a
text editor couldn't jump to a line. I do undrestand the background, I do
understand that all network related smartness is exported into the
netlist infrastructure, and it's all fine. But then why gschem doesn't ask
the netlist infra? Or why the netlist engine doesn't generate an ".lst"
(staying with the object example) gschem can read? And why gschem tries to
understand slotting in the first place, and doesn't leave it for the
netlister?
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. It just won't work. Not being able to get the GUI
identify some of the most basic building blocks is just plain wrong, no
matter what the architectural reason is. Not even if John will surely
hurry to mislabel this as an "integrated vs. toolkit" issue.
Regards,
Igor2
- Raw text -