Mail Archives: geda-user/2015/12/29/23:58:13
--Apple-Mail=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 29, 2015, at 9:17 PM, gedau AT igor2 DOT repo DOT hu wrote:
>=20
>=20
> On Tue, 29 Dec 2015, Evan Foss (evanfoss AT gmail DOT com) [via =
geda-user AT delorie DOT com] wrote:
>=20
>> On Tue, Dec 29, 2015 at 2:35 PM, John Doty <jpd AT noqsi DOT com> wrote:
>>>=20
>>> 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:
>>>=20
>>>> 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. ...
>>>>>=20
>>>>> It would be good if you could bring the design erros forward.
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>=20
>> Sorry, nothing will get me to adopt a flow that breaks manually named =
nets.
>>=20
>>>>=20
>>>> nets vs connections:
>>>> libgeda and gschem are only allowed to understand connections and =
even
>>>> then in a limited way.
>>>=20
>>> Limits to the smarts of the tool are good. Make the tool understand =
too much and it gets in the way.
>>=20
>> 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)
>>=20
>>>> 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.
>>>=20
>>> You can?t imagine doing this with a specialized tool?
>>=20
>> The order of events to back notate.
>>=20
>> 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.
>>=20
>> If that seems amilliar it is because this is mostly what Igor2 did.
>> Igor2 had PCB run more of it but still.
>=20
> Nope, my approach is totally different.
>=20
> 1. PCB exports a set of commands (I call it a patch)
An interface. Good. Is it documented?
>=20
> 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
>=20
> 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:
>=20
> - "pin 1 of U4 should not be connected to net Vcc"
>=20
> - "pin 1 of U4 should be connected to net Gnd"
>=20
> - "the value of footprint attribute of U4 should be dip(8)"
>=20
> So the "search" functionality in gschem is really searching for items =
on the patch that do not match the features of schematics currently =
open.
>=20
> Disclaimers for John (because I know he will repeat his agenda =
anyway):
>=20
> - 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=92t 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.
>=20
> - 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.
>=20
> - 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).
>=20
> - 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.)
>=20
>>=20
>> 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.
>=20
> 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.
>=20
>=20
>>>> 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.
>>>=20
>>> Functionality that gets in the way more often than it helps.
>>=20
>> You are right but the code is there and it works. (Igor2 proved it)
>=20
> 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?
>=20
> 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.
>=20
>=20
>>>> 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).
>>>=20
>>> 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.
>>=20
>> You just compared Apples to Asparagus.
>=20
> 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.
>=20
> 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?
>=20
> 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 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
--Apple-Mail=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWg2RZAAoJEF1Aj/0UKykRRh8P/293jirqqv60FtISgkKlzMW9
jPYRuNRkKuhi6A3XVhExcwRyOLXsWmgBeEEszhqqA5Wn/3+prCL9lrwv9m2SxVYB
G/quWJqUMwdX3qw4ROF3JrCQ2eFjEpXUrHlHqPHw32CBFPQtb6EexBuiMhltPWTT
Ygd6ETZlAhxbfcHyfi7PjHgZ7lU92x+z5n+ASkTm4JHUv//zDPRJr40Zc4W5tufv
ptZZVTDLS6YXFjRZE6YPAcNwCU8STy5u2xIqyWKUhqLHaR6ZVgaNgqsFHHm354YX
TJ3qRlb0YP7cvhWxVUiZzJr6st4ObCSX0gK/Jp2iXUkh6AKX8lKZbCox3WbEPb9Q
EVmk5rYQmwsxAjfSiQJ5lsRtAtboJECFwr407NQWpjA4oly60je//aR80SvXAmm7
zLRSy0PWWG25QVeKgDyVIXhkwdqT7AN3kATcglMQSuEcQy2D2667or4JAvpLd00I
51UbE5Hcex7EJQwafEM+0MDnWZmgilh4Yn7EqdR7fQy0h8NXpL9Bbtgf6zOhKNdl
N/pVAn4uG8N+VK0motQ735kQtzErOPHxX6RG4DhGQrpTvq5a/GS97NX7aNboMt4K
HC+a/oBcV8JP9uPS5kN/xTTxI7LVc8Dtfto5AaExHF8qsk5YSZGbGVTpHS0mHgI3
UTwBSlAT69a84Ug5csSb
=j5D7
-----END PGP SIGNATURE-----
--Apple-Mail=_823A7EF1-9AD1-4DEE-960F-DAB269E765D1--
- Raw text -