Mail Archives: geda-user/2015/12/29/14:35:31
--Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
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. ...
>>=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.
I did this ad-hoc a few months ago with Osmond, and it wasn=92t hard. =
The required tool is one that puts the netlist in a =93canonical=94 =
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=92t change. This would be useful in a variety of flows, =
I think.
>=20
> 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.
> 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=92t imagine doing this with a specialized tool?
> 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.
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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 =93make=94,=
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.
>=20
> 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=92s what it=92s for. Now, =
Roland aspires to make Xorn the universal foundation for such things, so =
maybe you should work with him.
>=20
> (Side note: Vladimir I saw your feature request for a scheme
> interaction window. I actually think that is very cool.)
>=20
> 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=92m a gey-haired refugee from the punch card era with three active =
braincells left. If can use it, why can=92t an actual programmer use it?
> 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=92t really that =
different from other Lisp dialects. We really only use a small subset of =
it.
>=20
> 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=92t need much change.
>=20
> 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=92s way too much ambition among developers to change our =
solid, proven geda-gaf foundations. There=92s too little appreciation of =
what they=92re capable of if you use them instead of fighting them. =
Thus, there=92s too little ambition to add tools and scripts atop them.
>=20
> 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.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
--Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08
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
iQIcBAEBCgAGBQJWguB3AAoJEF1Aj/0UKykRenQP/3nsWCfWYNiI0CrALAR0x3l9
198AzGwuBON8y8kif6/5BfLoj2v7WjpJ3SBzQ2H1j1X7NJrGc66w7stUTQceIN9R
ALuWluJXTwA6xJMmV9r2we5Liw2FYiK8ua5pPeB8k/CsrmZmH0Wu5+ISbylkXhrU
+Nt2Sty2cc4qUCaxgq8068hmrYHfk+e32kauKCQpenKyPoD+BL7ysO8/aLI+dp0A
Jop4msdOF3xAeZGdFqZ6C6oTAv6Qf6uCkjlq4RlLO0fsY3vQDvc7MOCbEH4t7ME/
da2V4680NzPJMZtRThArWGqjRxxGnQ1wJSXkatvN8DNsdUzp4dpoD8pVBHKVvTxF
2YBxz5XxiHpU5d7BL0ppId7uSormVkYVNFyJQrZUaktQHU8fOIq2bsJvSv+WVAZC
o1LPw2daWg6F8DZ0BiVtpSjb7oTrPzlo2a61BeXgv6S22UZwuGMh/3nVar943IYE
rFrxo6/rVxvHuwajALQSKexPq4w0c6rM6UpQ04b8UHg/bZMCQSawk/VTmnsWDo2N
YQxoFVtOK6XXLon4VTcwcKZDgwCRbqLlGqMVHXYz2Lo4y/5lDoAEFe2hdqzqzQ6s
yidtyeAw6j0q7beMQSkXUwmwMXcvMPY3WwUwuajxrypaH79yekwXMHeC/q2RsdIb
RbjN+HK7UrgVh2OvIfjb
=WUdv
-----END PGP SIGNATURE-----
--Apple-Mail=_A04BC94D-DCDF-4A2C-841C-27A5F4760B08--
- Raw text -