Symbol editing and the netlist

Schematic
41

You need to consider your interpretation for a minute, because it’s very, very strange.

The purpose of a high-level language is to generate machine language. The
advantage in using the HLL over writing machine language is human-readability.

No interpreter or compiler would ever have been written if the source code were only
for people to read. There was already something like that, and it’s called “a novel”.
Nobody writes code (in any language) just for other people to read - well, maybe some
profs do when they’re trying to make a point about programming style, but that’s not the
real world. Its PRIMARY purpose is to be fed through the tool that turns it into the
machine language the computer understands. Its secondary purpose is to be readable, understandable, and maintainable by humans. If you disagree with this
statement, please consult a computer science professor. Or my wife. She’s a complete
nontechnical blockhead, but even she gets this.

There is a valid case for using a schematic drawing solely and simply as reference
documentation, of course, and that’s when you’re creating the actual hardware by hand.
I’ve done lots of this over the years: Wire-wrapped or point-to-point soldered (we call
that “artisanal wiring” now) a prototype and documented it in the schematic, which can
be drawn by hand or in CAD - doesn’t matter, it’s just a picture.

But if you’re then feeding it through to a PCB layout system, the accuracy of that
drawing - as interpreted by the software, not how it appears to you - is the only thing
that matters. And the information it’s taking from the schematic, the list of pins and
connections, is in the form of the netlist. If your netlist isn’t perfectly accurate, the errors
will be reflected in the final product (the PCB). So the entire schematic capture
system’s responsibility is to maintain the integrity of the netlist, because none of the
remaining processes care at all what your schematic looks like. Don’t get me wrong -
I’m as anal-retentive as the next geek, and I want my schematics and layouts to be
gorgeous. But I also understand that the appearance of a drawing is a cosmetic
consideration that I (and others looking at it) appreciate, but doesn’t matter a whit in
terms of the actual design within the EDA system.

So I’m going to say it again: The purpose of CAD schematic entry is to use a high-level,
human-readable visual language to create a netlist. One more time: The ultimate
purpose of entering the schematic into an EDA system is to generate a netlist, because
you’re engaged in nonproductive exercise if all you’re doing is drawing a picture for
people to look at rather than building a database for the remainder of the EDA tools to
use.

A good EDA system is built to provide you with every possible tool and means for
creating (via schematic capture), then not screwing up, the netlist. A bad system is one
that fails in any of those respects. So you’re arguing against your own interests when
you say that KICAD’s schematic capture is just great, as long as you follow a very
strict set of rules that are extremely easy to accidentally break, and every time you edit,
you check the whole damn thing again to make sure that you haven’t inadvertently
added errors that the software didn’t catch. Why wouldn’t you agree that a tool that
works to both prevent and catch those errors is the superior, and more desirable, one?

I will never understand why people will foam at the mouth arguing against their own
best interests, usually because they’re wedded to a broken system and can’t clear their
heads enough to see how much better other people, who do it a little differently, have it.

I have no intention of veering off into a pointless political argument here, but this is a
very appropriate analogy that I think many here will immediately understand, identify
with, and agree with: That’s how those of us who live outside of the US and are
provided free health care by our countries view people in the States who rail against
“socialized medicine”. Why don’t they get how much better it could be for them? This
is like that.

1 Like
43

I’m with Paul. The primary purpose of both schematics and code is human readability.

If a human can’t read it to maintain it, then the fact that it compiles to a board or to machine code is not worth much. There are a gazillion lines of code on this planet with absolutely 0 value because they’ve been abandoned.

6 Likes
44

Thanks for the hint with Dave Vandenbout (devbisme) The video I searched was from him, probably on a Kicon about version 3. In the meantime I found a later version from 2019 where he already developed his ideas for script based automatic diagramm generation much more

1 Like
45

It may be strange to you, but it is true none the less.
If you can’t read the code, there is no use of pushing it though a compiler. It will just be “garbage in garbage out” Same for schematics. If a schematic is not drawn clearly, I’m not even going to bother with analyzing the circuit.

Humans always come first. Design time is expensive. Effort for maintenance and refactoring is expensive because it needs human effort.

The primary goal is to reduce human effort for a design, and especially for long term projects which will receive updates and refactoring over their lifetime, it is the human effort that is the main driver. A compiler (or a netlist) is just a part of the toolset.

No, it is not.
If there is a discrepancy between the visual representation and how it is interpreted by the software, then there is a serious bug that has to be fixed.

I do care. And I find myself more important than my PC software. If a schematic is not drawn properly, it won’t even get to the stage of generating a netlist.

Jack Ganssle has written books about this. He has been in the embedded software business and done lots of consultancy later on.

I didn’t say:

or better, it is a great piece of Open Source software, but that does not mean it can not be improved. KiCad has many flaws, and has been improved continuously for many years, and it will keep on doing so for the foreseeable future.

But there is also another side. I also like the simplicity of KiCad. Because it works straightforward it’s easy to learn and understand. I once paid for an EDA program called “Edwin” (That was 25 years ago). That program maintained a netlist independent of the schematic and when a wire in the schematic was deleted, it did not always remove the pin from the netlist, and this resulted in faulty PCB’s. I admit, it’s maybe not a fair example because it’s a bug, but it’s a class of bugs that currently can not even be made in KiCad.

I do agree that tools are meant to help you with preventing and fixing mistakes, but they should also be human centric and not get in the way of you doing things. In another program for example, it was not allowed to have the same pin number twice on an IC in the schematic. Sounds logical on itself, but it was very annoying. For example when I discovered a faulty schematic symbol because two pins were swapped, I could not rename pin 1 to pin 2, because pin 2 was already in use. I had to renumber pin 2 to pin 3245 or something, then renumber pin 1 to 2 and then find that other pin again and rename it to… Aahhrrg., was it 1 or 2…

Software like that both distracts me from the task at hand and annoys me. And as far as I know, this is a very important concept in KiCad too. KiCad should never get in the way of what a user is trying to do. The Human and it’s effort is key, and KiCad is a tool.

I’m not against some kind of netlist functionality in the schematic editor, but it’s benefits also have to be weighed against the con’s. And if the schematic editor maintains a netlist independent of the graphics on the screen, then the first thing you do is open up a big can of worms, and the software developers would have to tread very carefully to make it an improvement instead of a hindrance.

One of the things I really liked about KiCad when I started with it some 8 years ago was it’s simplicity and it’s straight forwardness. Over the years KiCad has become much more powerful, but it’s also loosing some of it’s simplicity. It’s a difficult business to maintain that line.

2 Likes
46

KiCad will not go in this direction. It’s a fundamental part of how the schematic editor works (by design) that the netlist is something generated from the schematic graphics. It does not live as a peer next to the schematic graphics, and it is not an entity that can be modified separately from modifying the schematic graphics.

That said, I don’t think the schematic graphics editing is perfect by any measure, and that will continue to improve (just look at the improvements made from V6 to V7 here to get an idea).

The best bet for this thread to go anywhere productive is for people to think about concrete ways that schematic editing could be more streamlined, that fit in with the KiCad paradigm given above, and then open feature requests for them on the issue tracker (if they don’t exist already).

1 Like
47

[quote=“craftyjon, post:46, topic:39271, full:true”]
KiCad will not go in this direction. It’s a fundamental part of how the schematic editor works (by design) that the netlist is something generated from the schematic graphics. It does not live as a peer next to the schematic graphics, and it is not an entity that can be modified separately from modifying the schematic graphics.[/quote]

Then we’re in agreement. The schematic and the netlist must maintain correspondence
with each other, and if the schematic is modified, that modification must be reflected in
the netlist. Conversely, if there’s a change in the netlist (e.g. via backannotation from
the layout if component designations are changed or pins or gates swapped), those
changes must update the schematics.

So to come full circle to my original posting:

KiCAD violates this requirement by damaging the netlist (and the schematic itself) when
a symbol is edited. What I’ve learned is that there are a lot of behaviours in KiCAD’s
schematic capture that are eager to trash the design (that is, to make changes that the
user did not explicitly and intentionally perform and does not want), requiring
unnecessary vigilance and work, and constraining the user in arbitrary ways, such as
penalizing you for needing to change a symbol after wires have been attached to it.

What makes anyone argue that this behaviour is good (or even acceptable) rather than
agreeing that it could be much better? That it could allow you the freedom of editing
symbols and moving stuff freely around with ease, a minimum of added effort on your
part, and full-time, active error prevention?

48

Not really. The netlist is the schematic, it’s not a separate concept in KiCad (even if it is in some other software you are used to, that doesn’t mean that it must be in all tools). Note I’m not talking about “netlist files” here which are a separate matter. Backannotation in KiCad works by changing the schematic graphics, which then result in a new netlist.

It seems like you are used to a certain workflow where once you initially draw a connection, you then must take some extraordinary action to change that connection. That’s not how KiCad works, and that’s not going to change. KiCad prioritizes making it easy to draw and modify the schematic graphics, and the netlist is derived from those graphics (not the other way around).

As noted above, if you have specific requests about how schematic graphic editing could be improved, we’re all ears over on the issue tracker. We may not choose to implement every suggestion, but we can discuss them one by one. However it’s important to note that KiCad works differently than the other software you are used to, and KiCad’s workflow prioritizes the graphic editing over the “netlist first” approach you describe. Neither is better than the other, they are just different. Coming in here and ranting about how your way is the only professional way isn’t likely to accomplish much, especially when you sprinkle in some bonus ad hominem insults and mild sexism.

5 Likes
49

No, there is still such a thing as objective truth. There is software that helps, and that
that does not. Your assertion that “the netlist is the schematic” (or vise versa), plays
with language in a manner that appears to have meaning, but actually hides the truth.

Put down a symbol and add two wires to it - which adds those two connections to the
netlist. Now edit the symbol and swap those two pins because it helps make your
schematic look better. When you return to the schematic, the wires will be connected
to the wrong pins because the schematic is the netlist and the schematic capture
package (including symbol editing) failed to follow along with what you actually wanted
to do, which was simply rearrange a couple of pins without altering the actual
connections.

Software that does this is not helping you. In fact, I’d go a step further and say that
in the absence of warning flags or rubberbanding or any other notification that
something has changed (and might be amiss), it’s doing harm by hiding what actually
happened. So I’m going to ask one more time: Why would you prefer that to a system
that understands what you’re actually trying to do and respects the connections you
drew, rather than breaking them for a very bad reason (innocent symbol editing)?

The difference isn’t “a matter of taste”. One approach is objectively better than the
other.

50

To quote The Dude: That’s just, like, your opinion, man. :slight_smile:

Clearly you’re not going to come around to this point of view today though. So my comments are mainly directed at anyone else reading/participating in this thread.

While your attitude and approach to this thread leave a lot to be desired, you have hit upon a legitimate difference between KiCad and some other tools (not all others, since there are plenty of other tools that work like KiCad). @paulvdh basically summed this up here:

KiCad’s philosophy is to allow incorrect states as part of your design and editing workflow. The presumption is that any mistakes can be corrected by a combination of automated checks and manual human review. This is an intentional and considered choice, not a bug or failing of the software. The development team made this choice because we believe that this approach allows for more efficient and less frustrating interaction with the software.

Because of this philosophy, you won’t see us add code that tries to assume too much about what is correct or what the designer intended, especially when doing so could be frustrating.

We take the stance that it would be in some situations more frustrating and limiting for KiCad to automatically try to “preserve” some state of the netlist when the user does certain edits than it would to just allow the netlist to be broken or changed, and let the user fix it the way they want to. So, the original complaint you started this thread about is by design from our point of view: we are never going to make it so that KiCad redraws your schematic for you when you edit a symbol in the Symbol Editor.

On the other hand, we do want to make it faster and easier to edit schematics. One way this could happen that is relevant to your original use case is by making it possible to drag around symbol pins inside the schematic editor and have any attached wires come along for the ride. There’s quite a difference between this possible future feature (both technically and philosophically) and the one you ask for: the change to the surrounding schematic is made in real-time and interactive with the user’s drag action, so the user can see if they are happy with the rerouting or not in real-time. The change also only impacts the immediate area the user is interacting with, so it becomes more clear which parts KiCad is touching.

This is just an example of a more specific request that could be made on the issue tracker and discussed. These kind of things can get traction a lot more easily than broad assertions that there is One True Way to design an EDA tool.

9 Likes
51

A brilliant idea!!!

Probably, if this concept was an actual function, to OP would never have started this thread, eh @via

2 Likes
52

Oooo… that sounds like a terrible idea, a real recipe for chaos. I believe that symbol
editing should take place in the symbol editor, which (as I’ve already pointed out) is
actually pretty nice. In your suggested case, what happens when you move a pin from
the left side of the symbol to the right? Each of the four sides of a symbol body polygon
has a “proper” pin “subsymbol”, so does your pin change from a left-side pin subsymbol
to a right-side subsymbol when you move it?

53

It’s just speculation, but I guess this would be very similar to how moving of hierarchical pins in a hierarchical sheet symbol works. You can drag the pin around, but it will stay attached to the closest side.

I’ve never really understood the distinction between a schematic symbol and a hierarchical sheet symbol. Having the possibility to add a schematic (in addition to a footprint) to a schematic symbol would be a great enhancement in the use of “design blocks”, For example some breakout board for an IC, in which the the sub PCB can be used as a quick prototyping tool, and then makes it easy to transfer the IC plus supporting footprints and tracks to the PCB as a preparation for later editing and mass production.

2 Likes
54

And is the modified symbol saved in a library, and under what name???

Many questions need be asked.

The “concept” is what was met with my approval. :slightly_smiling_face:

55

There’s an wishlist item in the tracker for this. I was sort of thinking of going at it the other way around though: being able to assign a symbol graphic to a sheet.

But it’s worth saying that your approach didn’t even occur to me, so I wouldn’t want (at this point) to suggest either one would be better than the other…

1 Like
56

I’ve been doing electronic design since the late 60s. My previous software was Eagle EDA. It had what you want but fortunately, I could turn it off. When on, it would splatter my drawing.

I have products on the market designed with KiCAD. It most certainly is capable of professional work. You either adapt to the times or you don’t use modern tools. The other commenter is correct. KiCAD isn’t for you. You can buy Eagle from Autodesk for a couple thousand dollars. Maybe that would suit you better.

The workflow in KiCAD is that you first fix your symbols and footprints before you start making connections. That’s logical and is the way most engineers work.

John

1 Like
57

John:

I’ve really been trying to avoid the rod length checks here, but I’m finding the “Maybe
KiCAD isn’t for you. Perhaps you should spend X on Y. Maybe you’d be happier if…” to
be both passive-aggressive and incredibly condescending. So here’s my answer:

Here’s where I’m coming from. I got my start as a bench tech in the mid-70s, EE early 80s, about 8 years hand taping layouts before about a dozen years on PC EDA before making the step up to Mentor Graphics under HP-UX and yes, putting products on the
market with it. Mentor blazes, is worth somewhere over $100K (at the time, more
than $25K per seat for Design Architect - that’s what they call schematic capture -
alone), and I have a license that doesn’t expire. Mentor’s UI is staggering in its brilliance; there are no hotkeys and no pulldown menus (vs. the menu - longer than my
laptop screen is tall - with 26 items, that you get in KiCAD when you select something
and then right-click) and everything is done via mouse gestures (“strokes”) that mean
your hands almost never touch the keyboard and your eyes never leave the center of
the screen, which matters if you know a damn thing about human factors. Now that
I’ve played, in recent years, with both Eagle and KiCAD, my respect for this almost 30
year old version of Mentor is growing by orders of magnitude. There’s a very big chasm
between the worlds of high-end EDA and low-cost PC EDA. Designers using expensive
and genuinely powerful tools know what’s going on down in the cheap and free world
and don’t switch because they have no interest in the compromises. Yet despite their
almost certain ignorance of how things work in seriously professional systems, open-
source users don the mantle of moral superiority because their software is a labour of
dedication and true love rather than filthy lucre, then apparently assume that moral
superiority somehow confers technical superiority.

I have historically strong connections to the open-source world by my associations with
major projects and their people (names you all know, and which I’m not going to name-
drop) so I’m on record as an ally and supporter. That’s why I’m prepared to take KiCAD
seriously.

The reality is that I strongly doubt there’s anyone among those who have participated
in this discussion (other than me) who’s worked with Mentor (or a comparable tool), so
you really don’t have any understanding at all of what I’m trying to convey, because if
you shoulder-surfed five minutes of me hacking around a schematic, all you’d be able
to say is “wow…”. On the other hand, I’ve used both, so that allows me to draw
comparisons. Perhaps I should bang out a little youtube video of this system in action
so you can come to the conversation at least sort of armed.

So why, you ask, would you want to bother with slumming it in open-source EDA, if
what you have is so damn good? And that’s an excellent question. First is
convenience. The amazing system I use is on a less-than-amazing Unix workstation
that’s nearly 30 years old, so that means it’s really a pre-modern-Internet machine e.g.
there’s no web browser that runs on it, making it rather isolated and inconvenient for
work other than EDA. Second, nobody else runs it, and my interests at the moment,
and the projects I’m working on, have a lot to do with the ability to share them with other
folks working on related stuff. So those twin pressures are driving me to modernize,
and if KiCAD is both free and a credible tool, it makes it a lot easier for the people I
want to exchange project work with to set themselves up with a compatible system.
Oh - and I’d like to be able to work on a laptop rather than the big glass tube on the
PA-RISC system in my lab.

The problem is, at this stage in the design flow I’m finding that KiCAD just isn’t credible
compared to what I’ve been using for more than 20 years, which itself is quite
astonishing - I would have thought that with so much interest and CERN money and
people and all, KiCAD could at least crib the best techniques from software that came
out 35+ years ago (and doubly so because there’s very little chance of patent
infringement). But now that I’m here and sincerely trying to give it a serious, honest go,
almost everything I’ve seen of its schematic capture is just awful, and evidently
entrenched in the “we’re open-source and awesome and if you don’t agree, then maybe
you just don’t understand and it’s not for you” cult mentality.

So on one hand I feel like I should push through it, suck up the really terrible
requirements of using this system (“make sure your symbols are perfect before you
start and check everything a hundred times before starting a layout”) long enough to
get to layout, where, I’ve been told by trusted friends, a wonderful world awaits. On
the other is the instinct to return to tools that just work and come back in a couple of
years to see if this stuff has grown up enough to take another run at, and forgo, at
least for the time being, the modernization and ability to share that brought me here
in the first place.

And that’s just a tough choice I have to make for myself.

58

As suggested, please fill out a bug report and link it back here. I’ll spend the time to read it.

EDIT: disregard.
muted.

59

Then you did not read my post here only a few hours ago: We are changing from Xpedition…

Our last license was version 2007, today still valid but application cannot run on W10. Its possible to use it in isolated VM but there is no future for that system. We discontiniue Mentor as DesignCapture is incompatible to DX-Designer. If changing again, we are free to change to anywhere why many users and even some Mentor salesmen went to Altium. Years ago we had a total fail and complete reset of all designs for changing from Cadnetix to Mentor. Reasons were deeply hidden in the library formats and we also failed more or less with self written converters. 1988 were about 40 EDA companies on the market. Almost nothing of them exists today. Even the golden eagle is loosing massive flying height. A thing what probably never happens with Kicad.

Not everything was well with Mentor but probably you know how the CDB/PDB and cell libs work in comparison to Kicad symbols and footprints. Following the FOSS idea, Kicad is not only a EDA tool. It is everybodys laboratory for new EDA technology. The task for us old-stagers is to contribute good ideas what already worked formerly more or less.

1 Like
60

I throw this back at you:

With that attitude towards “the community”, combined with your apparent superiority feelings I have lost all interest in communicating with you. I also stopped reading your post right there.

Perhaps follow a course in social skills instead of technical stuff. Meditating also helps, If you do this for half an hour each day for a year or two, you develop a sort of “3rd person view” in which you are able to have a much more objective view of your own behavior towards others.

I’ve also set this topic to “muted” and won’t read nor respond anymore.

5 Likes
61

i didn’t know this is a thing!
thanks for let me discover this nice forum feature! :slightly_smiling_face:

1 Like