Mail Archives: geda-user/2015/12/30/00:20:54
On Wed, Dec 30, 2015 at 4:58 AM, John Doty <jpd AT noqsi DOT com> wrote:
>
> On Dec 29, 2015, at 9:17 PM, gedau AT igor2 DOT repo DOT hu wrote:
>
>>
>>
>> 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)
>
> An interface. Good. Is it documented?
So far no one except me is interested in merging it. Why document
something no one else has accepted?
>>
>> 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)"
That is what I mean by changes to connections.
>> 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.
>
> 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.
>
>>
>> - 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. A common netlist/bom format with a canonical form (so equivalent netlists would be identical) would be a useful intermediate.
>
>>
>> - 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.
>
> Why are you not using the Scheme scripting that Peter Brett worked so hard to make useful?
>
>>
>> The other thing is what exactly happens when you click on a net.
>
> The overloading of that is a problem in the current GUI.
>
>> 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?
+1
I have long wanted to have back annotation of netnames so that I can
go from schematic to netlist to spice and then back to schematic to
understand what the context of some messages mean.
>> 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?
Some of us think that it would be better if more of this worked out of
the box. What is wrong with including the stuff Igor2 described in
geda? It breaks nothing and could be supported by other tool chains.
>> 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.
>
> John Doty Noqsi Aerospace, Ltd.
> http://www.noqsi.com/
> jpd AT noqsi DOT com
>
>
--
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2
mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----
- Raw text -