Mail Archives: geda-user/2015/12/29/15:04:45
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.
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.
>> 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)
>> 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.
>>
>> Basically I see value in not forcing every thing to make nets and
>> connections equivalent *but* more of the the mechanism that grants
>> them equivalence should be available in libgeda so the whole suite can
>> use it more easily and not just gnetlist.
>>
>> connections vs buses:
>> Because we don't want to acknowledge connections are in any way
>> equivalent to nets we also can't group nets and call them a bus. The
>> inability to group them in this way leads to the inability to do cool
>> things like set properties for a whole bus when you go to rout a board
>> or do a simulation.
>
> You want an integrated tool, not a toolkit. KiCAD, not gEDA.
No I don't look at what I am suggesting.
>>
>> scripts:
>> I see scripts as having a few flavors. Throw away, project specific,
>> and prototype. The first two are mostly self explanatory but the last
>> one (prototype) I thought was how we were to see how the user
>> experience would be if we did X to the core. We are generating a low
>> of the first two and almost never any of the third. Even when it does
>> happen massive opposition hits when X new idea is suggested as an
>> addition to the core of geda (libgeda)
>
> While I see scripts as production tools. The basis of automation, allowing me to avoid the GUI altogether when appropriate. Type “make”, and three minutes later have all netlists and BOMs built. data integrated into PDF documentation via LaTeX, for a 3500 component project. Geda-gaf scales up to real automation very well, without forcing you to do it in any rigid way.
Yes I use makefiles and yes I appreciate automation but nothing I have
described will break that. You drag that argument out every time
anyone suggest change.
>>
>> I want C plugins in libgeda it would make moving code that is a cool
>> plugin into the core easier.
>
> Fighting the paradigm. We have Scheme. That’s what it’s for. Now, Roland aspires to make Xorn the universal foundation for such things, so maybe you should work with him.
While I support Roland's right to do this own thing with Xorn this is
what I would like to contribute. Also you have udder this same opinion
before.
>>
>> (Side note: Vladimir I saw your feature request for a scheme
>> interaction window. I actually think that is very cool.)
>>
>> scheme is good and bad:
>> The effect of having scheme drive things in geda instead of just as a
>> language was good in that it bent the programming style of C code
>> contributions into a cleaner form than we might otherwise have had. It
>> is bad though because having scheme drive C makes a lot of C
>> programmers nuts.
>
> I’m a gey-haired refugee from the punch card era with three active braincells left. If can use it, why can’t an actual programmer use it?
1. Why does everyone assume my background is CS?
2. I can use it. I just don't want too and I am not alone in that.
>> It is also bad for long term maintenance because the
>> number of available scheme programmers is small and getting smaller.
>
> Lisp is having a resurgence with Clojure. Scheme isn’t really that different from other Lisp dialects. We really only use a small subset of it.
Look at the graphs github generates of language use. I am not
suggesting we go with what is most popular but there is something to
be said for not using a language that's largest application was in
teaching programming.
Trying to save gEDA by tying it to scheme is like trying to save a
lifeboat by tying it to the Titanic.
Scheme is there and I am not advocating it's removal. I am just saying
that Vladimir's plan to replace our already existing C with more
Scheme is probably not going to help use gain contributors.
>>
>> clunky use of glib:
>> I don't like the way glists are used in libgeda. I accept glib as a
>> dependency because glib is also used by gtk and geda is gtk heavy but
>> still. If we ever put a hid on geda like we have on pcb it would be
>> nice to remove that dependency.
>
> Deep down in stable code that shouldn’t need much change.
Agreed. I just thought people would oppose it.
>>
>> slots:
>> The slotting mechanism is fundamentally worthless for a the majority
>> of cases were I would want to use it. Look at the 7400 symbols were
>> they have a whole extra symbol for the power pins. That is
>> conceptually IMHO something that should be a slot but you can't do
>> that because all symbols have to have the same number of pins and
>> geometry.
>
> I think most of us agree that the slotting mechanism is flawed. This is the kind of thing we should be doing with Scheme plug-ins. A related problem is the model that gnet-drc2 imposes on designs. I have been working on improving DRC (gnet-check-duplicates and gnet-check-pincount).
>
> I think there’s way too much ambition among developers to change our solid, proven geda-gaf foundations. There’s too little appreciation of what they’re capable of if you use them instead of fighting them. Thus, there’s too little ambition to add tools and scripts atop them.
I think there is a way to have a tool that is both power full and
delivers all the functionality we want in the command like while
having a user experience that does not require exiting the GUI to open
a text editor for day to day projects.
>> In places were slotting could be cool we don't use it right in the
>> standard symbol library. Take the symbols for the larger xilinx chips.
>> I would rather each section of the chips I/O be it's own slot so I can
>> show the FPGA connections near what they are connected too instead of
>> putting the FPGA on it's own page (most of the time). Likewise
>> breaking it up into more symbols would mean not wasting most of a page
>> on the empty area inside the FPGA symbol.
>
> I just do that with pins2gsch. Draw a small box for the FPGA, with a bus running to it. For my most recent project, the connections are extracted from the Vivado export, so when the FPGA designer scrambles pins on me, it automagically propagates to the netlist.
I have to think about that.
> 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 -