Symbol editing and the netlist

Schematic
62

@janvi :

I’m sorry - I missed that reference in the storm, and obviously you’ve been using high-
end EDA longer than me, since you used Cadnetix. It would be great to have you offer
your views on the relative merits of the schematic capture (both UI and the overall
handling of connections) between Mentor and KiCAD so we can both speak out of wider
experience and I won’t feel like I’m shouting into a bucket. Also, it’s worth keeping in
mind that I stuck with V8 because mine was an all-Unix shop and I didn’t want to move
to the newer windoze versions of Mentor, even though I would have gained the benefit
of the VeriBest autorouter, which has always had an excellent reputation.

Yes, in addition to the specific reasons for my considering migration to something
newer, there is also the burden of Mentor being extremely complex, but that isn’t really
relevant to the present conversation.

Since we agree, though, that greybeards like us should be bringing as many of the
best ideas we can to a project like this, please share with me your feelings on the UI.
I really do think that Mentor’s UI - built almost entirely around the strokes and select
filter, with almost no “hot keys” or other distractions from the mouse and the active work
area on the screen - is extraordinarily fast, efficient, and elegant, especially when
compared to KiCAD’s (to me, at least) confusing and inconsistent pointer state
behaviour, uncounted hot keys, enormous pull-down menus, status bar so far away
from the center of focus that it might as well be in the next room, and that it really just
doesn’t seem to take the idea of a “connection” seriously.

So do you not agree that KiCAD wouldn’t be just a good tool, but a great tool, if it
implemented a similar UI? Because it seems so obvious to me that if the original
authors had simply done their homework and surveyed the techniques used by even
a reasonable sample of those many EDA companies of the time, they could have
come up with something so much better. Was it fear of patent infringement (which I
spoke to earlier - any that might have applied are surely expired by now). Or perhaps
NIH (not invented here) syndrome? Because there’s no excuse for that either; in
Stravinsky’s words, “Lesser artists borrow, great artists steal.”

1 Like
63

When I use CM choke it happens that while designing PCB I see that I should swap coils. I then mirror the symbol at schematic and ‘done’ (the same with terminal blocks that I find that should be mirrored). If I understand you well schematic editor working according to your description would not allow me to do it so simply, because it better understand what I want to do. I don’t follow this reasoning.

Agree 100%. I hate if the program knows better than me what I want do to. If I were mirroring the CM choke but program instead reconnecting wires (as I want) would cross them to preserve my previous netlist it would be a kind of behavior I hate.

2 Likes
64

As a person that had the “opportunity” to use Mentor expedition on my Internship I have to disagree. Putting all the tools on the 15 toolbars, not having a way to customize screen panning and very limited scope of the mouse strokes meant that a lot of common tasks were very time intensive. Which is a shame since the feature set is huge. Still every PCB I designed with mentor was a struggle with the UI, even if that was because it is so different from literally any other software out there.

65

Mentor would allow you to do this a couple of different ways, depending on how the
symbol was created.

First is the obvious one: You disconnect the four wires, flip (mirror) the symbol, then
reconnect the wires. To get into deeper detail, here is (and I’m working from memory
here, I’m not in front of the screen) the sequence:

  1. Use mouse stroke to open select filter.
  2. Click “connections” button.
  3. Use mouse gesture (swipe) to close select filter.
  4. Enclose choke in mouse box, which selects only the connections.
  5. Mouse stroke “disconnect” to disconnect the wires from the pins.
  6. Open select filter, uncheck “connections”, check “symbol”, swipe to close.
  7. Click on choke symbol.
  8. Mouse stroke “move”, then choose “L<->R flip” on keyboard (though I think it can be
    done with the mouse too).

Now, at this point (assuming your symbol was left-right symmetrical and that flipping it
caused the four pins to land again on the four wires), the pins coincide with the wire
ends, but they’re not connected. Because of this you’ll get a warning flag on each pin.

  1. Enclose the symbol (including all four pins) in the mouse box.
  2. Mouse stroke “connect” connects those four pins again.

That all takes place in a couple of seconds and your eyes never leave the center of the
screen where your symbol is. No pull-down menus and probably don’t even need the
keyboard.

Slightly less obvious, but better and faster: If your symbol was created (or you can do
a simple edit to make it this way) as two separate coils in a single package - like the
individual gates in a 7400 - and they were indicated as “swappable”, it’s simple:

  1. Select the “gate swap” function.
  2. Click on any of your four pins, and the others will light up, indicating which coil you
    can swap with (according to how it’s defined in the symbol).
  3. Click on one of the pins on the other coil, and the two pairs of pin numbers on the
    symbol will swap, so you don’t actually have to go through the disconnect, flip, and
    reconnect described above.

(edit: Oh, sorry, I was thinking transformer symbol rather than CM choke, so in that
case it’s a an up-down flip, not left-right - but you get the idea. Also, the gate swap
information isn’t actually contained in the symbol, but in a little ASCII file called a “map”
file that defines the relationship between the schematic symbol and layout symbol pins.
Presumably in KICAD it’d be included in the symbol itself.)

66

Please keep in mind that I’m limiting the present discussion (which is already pretty far
OT in places) to Design Architect (schematic capture) in V8. I’ve never used
Expedition, so I can’t comment on what they changed by then. And though there are
basic common elements between schematic capture and layout (like strokes), layout
obviously brings a lot more complexity.

67

To be honest, practically there is not that much diffrence between Cadnetix and Kicad. Cadnetix proprietary keyboard used F-Keys very similar to todays Kicad. Possible for everybody to learn in a few minutes. Many things like the padstack library were first dropped and then introduced later again by Veribest. The first schematic was ACE (Advanced Circuit Entry) and Ace+ what was probably the same on your machine. We pronounced this as “Scheissplus” in our (german) office what later changed to compatible design capture. What I miss a little is the way of the 3 button mouse use for zoom and pan. I have problems with todays ergonomy of wheel mouse and one can hardly buy a 3 button mouse without wheel today. But this is a topic beside Kicad.

You didnt miss anything with not changing to windoze. The Microstation universal CAD based PCB editor was dropped soon for license reasons. The first versions of the advanced editor were fast but crashed every 5 minutes. Another thing I miss is any equivalent to the Parts Data Base (PDB). Parts of this aspect pops up again and again here and there but for the moment I dont plan any comments as I have not understood and tried myself what @craftyjon contributed with MR Database Libraries (#7436) · Issues · KiCad / KiCad Source Code / kicad · GitLab Probably I am going to wait for V7 and meanwhile finishing my boards.

For readers who dont know here is what I am comparing from 1988:
http://www.sleibson.com/assets/applets/Cadnetix_Brochure0001.pdf

68

@janvi :

Even to an English-speaker like me, “Scheissplus” is very funny.

I agree with you completely on the three-button vs. mouse-wheel thing. I don’t like the
tactile irregularity, or that in one context the wheel is a Y-axis movement and in another
it’s a Z-axis movement. I’ve actually been hunting for a three-button USB mouse w/o
wheel, and they’re surprisingly hard to find. The only ones I can readily spot are old
Sun mice on ebay, so I’ll probably snag one of those.

69

On a personal note:

To everyone here (including those who tuned out), Happy New Year!

I know perfectly well how harsh I can come across as in debate (whether it’s a bug or a
feature depends on which side of the argument you’re on), but at a personal level I do
try to be thoughtful.

2 Likes
70

Oh boy, I was trying to avoid this topic but on this boring post NYE Sunday morning this snippet is just too good to pass on.

Here’s how you do it in KiCad:

  1. Press X (Y depending on flip direction) with mouse over the symbol.

Done. That’s it.

Compare that to the “simple 10 step process” outlined above.

Do you see now what people mean when they say they actually like a different approach? That something different doesn’t necessarily mean “wrong and wrong, PERIOD”?

KiCad is not perfect, of course it can and will be improved. I like the idea to be able to drag pins around maintaining connections when you need to. I also like it to be users choice and not default behavior forced on you by the program that needs to be disabled every other time.

I also see why some people would choose to have the kind of netlist maintaining enforcement that you describe mentor is doing. I wouldn’t use it often if at all but hey, in a perfect world where KiCad has unlimited funding and plenty of devs to throw in any and all features in, then why not (as long as it’s optional)? This isn’t a perfect world and KiCad has to pick and choose which features to implement. And a feature that deviates so far from design philosophy of KiCad will not be high on priorities list.

You are also misunderstanding why people are defending KiCad. It’s not because it’s open source or because it’s free. Go to altium forums and you will get similar reactions from people who payed 5 digit sums for their proprietary software. When you are telling people they are wrong for not agreeing with your preference, even if you don’t see it as a matter of preference but as an “obvious” logical choice, they take it as an attack through questioning their judgement.

Some have seen this pattern too many times and choose to just distance themselves from the conversation as you have seen in this thread too.

6 Likes
72

Of course. But as has been made abundantly clear here, the concept of a
“connection” actually means something in Mentor and is apparently meaningless in
KiCAD. And that’s the fundamental difference underlying the entire discussion - if you
have no connections, there’s nothing to rearrange, which sure saves a lot of work!

So I hope that wasn’t the ace you were keeping up your sleeve to finally vanquish me,
because I suggest that you, as the saying goes, get back to me when a man bites a
dog.

In case there remains any confusion, I’m not here to champion Mentor over KiCAD -
that is not a productive argument. But the concept of a meaningful connection isn’t
unique to Mentor. My first EDA system was a program called EE Designer running
under DOS in the late 80s. I chose it because, unlike the dog’s breakfast (usually) of
OrCAD plus some arbitrary layout-only program that most people opted for, it was fully-
integrated and symmetrical and even useful for reverse-engineering (which Mentor isn’t)
because you could enter a layout (based on the board you’re working from) and back-
annotate to schematic. So even 35 years ago a cheap (about a thousand bucks, iIrc)
PC package had, in schematic capture, a clear and useful understanding of
connections that KiCAD in the present day lacks.

In fact, I probably still have a running copy on an old PC around here somewhere. I
still used it from time to time to bang out little quickie PCBs after I became a Mentor
user because it allows you to do a layout without first doing a schematic.

73

BEST. COMMENT. EVER.

I didn’t know about the “muted” function, but it’s now ON.

2 Likes
74

Yeah, boasting using some $100k+ software doesn’t make anybody a better person. I guess Mentor in this thread is like Protools for some mixing engineers. An excuse to show superiority, despite lack of creativity and understanding that there exist different ways to achieve the same goals.

Aside from this… Happy New Year everyone, let’s keep making KiCad and our projects even more awesome!

Tom

3 Likes
75

You misinterpreted me a little. If you read it, my main point was to illustrate that despite
it being a truly awesome EDA suite, due mainly to its age it has serious shortcomings
which are now leading me to shop around and have landed me here. So I’m not here to
crow about its superiority, rather to say “this is how the big boys do it, perhaps some of
these ideas can be brought here to make users like me much more inclined to switch to
KiCAD.”

76

Don’t you really mean “this was how the big boys did it”… thirty years ago?
How are things done with a current Mentor? Personally, I have no idea, but do you?

So a bunch of developers arrive and “Old-Mentorize Kicad”. Where does that leave the Eagle and Altium users? Will those changes to Kicad make them more comfortable in transitioning?

Craftyjon threw up an idea to be able to move pins, with wires attached, on the schematic. You instantly dismissed the idea.
Did you give it any real thought?
Someone in his position would certainly consider pin orientation.
There is no need to substitute the library symbol as only an aesthetic modification has been made and that modification is automatically held in the schematic file.

Overall, that feature would save bucket loads of time and effort messing around with the symbol editor and wire jungle, and, in this case, make the “nets on schematic” argument redundant. It also still allows @qu1ck 's “one key” mirror (or rotate) example, another time and effort saving advantage, over your old package.

Certainly I understand your lamenting the imminent demise of a long time friend, but just expounding your views, with praise, for an old version of a different programme doesn’t really help with the advancement of Kicad.

Now I’ve said my piece.

Happy New Year all!

77

This is the biggest “Tempest in a teapot” that I have yet read on this site.

I mean, really - how often do people actually re-arrange a symbol? Once it’s designed and confirmed, it’s done. Do people really want to change it on each different schematic they use it in? That sounds insane to me.

3 Likes
78

Tempest in a teapot - I wholeheartedly agree.

But “insane” to want to modify a symbol? Nothing could be further from the truth. The
larger (in pin count) the parts you’re using, the greater the chance you’re going to be
editing them as the design evolves. All you can do when creating a symbol for the first
time, especially with a part you’re using for the first time, is take your best guess, but
you have very little chance of getting right (enough) on the first try. Mentor (and I’m only
using its name to indicate that it’s the package I’ve been using for 20 years, not for big-
swingin’-dick points) puts a version stamp on the symbol every time you edit it, so if I
were sufficiently motivated I could pull up one of my more complicated designs and dig
around to see how many revisions the symbols went through. You might be surprised
at how high the count can be.

Incidentally, that version stamp isn’t just for yuks - everything in Mentor is versioned like
that, so that the system’s checks can make sure that all the various components of a
design are properly in sync, because if it detects a discrepancy between the versions of
things last time the design was checked and the versions on a subsequent check, it
errors. This is consistent with my core argument here regarding connections and the
netlist, which is really about the system working as hard as it can to keep you from
messing up your own design.

There’s been a lot of talk here (less on my part than others’) about the importance of
well-drawn schematics, and I’m all over that. If I’ve connected a couple of groups of
pins from a high-pin-count chip together into buses (using the angled signal-to-bus
joiners), and especially if adjacent bus groups happen to be angled in opposite directions, you often get wires crossing other wires where they join the buses, creating
serious confusion. Now, as I’ve explained, because the actual connections are what
count, you can leave that alone, ignore the warning, and proceed knowing that your
netlist is still sound - but it looks really confusing. So you pick up one of the groups
of pins and move it away from the other group .05" or .1" to eliminate those
intersections. In a complex design with high-pin-count chips (and I’m just talking about
common parts with a few hundred pins, not even extreme like more than a thousand)
you can find yourself making little adjustments like that ten, twenty, thirty times.

Or you’ve got a part with a bunch of I/O ports, and you’ve gotten them wired up to stuff
all over the drawing, and everything looks great. Then - and Atmel’s AVRs are famous
for this - you discover that the counter/timer you were sure was on Port D because it
was there in another chip in the same family that you did another design with… is on
Port E in this one! Buggah! So whaddayagonnado? Rip up wires in groups of eight
and redraw the whole damn drawing? Of course not. You edit the symbol and swap
the ports around and you don’t have to touch a line on the schematic.

So we’re not talking about once-in-a-lifetime edge cases, not by a long shot. Symbols
get edited with regularity.

79

That’s a perfectly valid question, and you’ve asked a bunch of good ones here, so I’ll
try to address them indivdually (if I can do that without screwing up the quoting and
unquoting, which keeps going wrong for me despite my efforts). Yes, that’s how it
was done in my ancient V8. And no, I haven’t used newer versions, so I’m arguing
for the really great things they did then, not that Mentor is wonderful now and always.

There were a few things done there that I still think are nothing short of revolutionary,
primarily the all-mouse, nearly-no-menus-or-hotkeys UI. But I’m trying not to focus on
that here, rather the issue of the representation and meaning of connections. With the
demise of the Unix workstation and wholesale shift of CAD to PCs, it’s certain that the
UI was altered (I’m tempted to say “compromised”) by pressure to make it more
homogeneous and consistent with the windoze interface. But I very much doubt that
they’d have tossed out the meaning of connections. That just wouldn’t make sense.

That’s actually a highly loaded question that misses the point. I’m not here to
“Mentorize” (old or otherwise) KiCAD. Nor should anyone be expected to try to
Eagleize or Altiumize it. That’s just not the right approach. What should happen
is that as much user knowledge and experience from as many different packages
as possible be considered, and the best ideas and features from all of them be adopted.
Yes, it’s an idealistic view, but you don’t make the best anything without using all the
best parts you can.

Yeah, my initial thought was that it sounded like a bad idea, and no, I didn’t give it
further “real thought” because I don’t think I have the necessary information to consider
it in greater depth. It’s an engineer’s-gut thing - my first answer is what instinct tells me,
and that’s the jumping-off point for a vigorous exchange of ideas in which I’m completely
open to being convinced otherwise. In this case, though, I’m not the guy who should be
in on the conversation, because I just don’t know enough about KiCAD to grasp the
deeper implications - my first reaction is just that it seems messy. And if I were in a
group tasked with considering the idea, the first thing I’d ask is “How much effort would
it take to prototype it so we can play around and see if the idea holds water?”

You may be totally right on that count, but I still sense a high potential for more
confusion in a UI that I already find confusing. I mean, when you have a pulldown
menu with 26 items, you already (arguably) have too many choices at hand, and more
choices related to editing a thing where that thing isn’t normally edited might make it
worse.

As the saying goes, reports of my Mentor system’s demise are highly premature. I’m
not lamenting anything yet. I think there’s a good chance I’ll bite my lip and push
through what I know is a serious problem to see the design to completion. I may find it
extremely unpleasant, but without seeing this through to the Gerbers I won’t be able to
honestly say “I’ve evaluated the package”. Along the way I expect to continue to offer
what I think are better ideas for KiCAD’s improvement, particulary the mouse strokes
UI, which, once you grasp it, will change your life. Maybe I stay, maybe I go. Too early
to tell.

I appreciate the thoughtful consideration, and you too.

80

It’s of course a valid argument that some other than the current ubiquitous and universal mouse/menu system would be better for efficiency. But this is a very pragmatic problem: for usability something which is known already is better than something which must be learned. As much as the benefits for the KiCad (or any other software or device) project are considered, if 5 “customers” would accept the product because of or despite the UI paradigm and 10 would reject it because of the UI paradigm, the former must be followed. I doesn’t help to be the most intuitive, coherent, revolutionary and effective interface if the potential users reject it for any reason.

Like it or not, the moment the Windows desktop, MS office and some newer popular EDA package start using similar gestures than you old Mentor, the KiCad project will certainly consider it seriously.

Until then, the best you can do is to record screencasts with Mentor and KiCad to show some similar tasks so that we can see how they are different and do comparison. We can’t try the old Mentor and describing it with words isn’t useful. If there’s a chance the gesture interface could be added to work parallel with the standard interface so that it doesn’t interfere with the standard UI and workflows, maybe someone with coding skills is convinced to try to implement it in a way which would be accepted to the codebase. I don’t see a reason to reject this categorically, but there are several preconditions. What I’m 100% certain of is that the new paradigm must not disturb the current paradigm, so it should be optional.

If I remember correctly, I have seen mouse gestures being proposed in the past. I don’t remember what the response was and why we haven’t seen anything about that later.

1 Like
81

For the moment I tried your hint using simple screen recorder from other thread and it worked well. Unfortunately Xpedition is on a W10 VM where other video capture is required. If I have time I am going to record some situations for comparison what is better or worster.

The situation is like a trumpeter decides to visit a violin makers shop. He will not find for what he is searching for and the reason is neither the quality of the violins nor his skills as a musician.

82

That’s a tricky argument because the answer is both yes and no. It’s always “easier”
in the short term, to stick with what’s known. But if, overall, the new thing has been
demonstrated to hold clear advantages, a modest investment in learning the new
technique will pay off in the longer term.

Sure. But there will always be a small core of users whose interest may be piqued
enough to give it a try - the “early adopter” crowd. So if it were capable of being
modularized so one of those could swap it in and switch it on in place of the existing
UI - take it for a test drive - then the chance of it getting a fair evaluation is much
greater.

Well, in the case of mass u$ product, that’s obviously not going to happen - the UIs
they employ are far too entrenched for that, and this really is a CAD-oriented thing,
where the actions are groupings of objects, selection, movement, reorientation,
duplication, connection, routing, etc. Not all strictly EDA, but certainly of much greater
interest in the CAD context.

Absolutely right - I’d resolved to get a few minutes of typical edits just to convey the
sense, because it’s very difficult for words to do it justice. My problem is simply a
mechanical one - I’m working on an old HP PA-RISC on a big RGB glass tube, so
recording that video output is a nontrivial matter and I’d have to resort to setting up a
camera in front of the monitor. Fortunately, @janvi is working under windoze and can
apparently use some of the usual tools, so let’s see how that turns out.

Absolutely. Never in 1E6 years would I suggest breaking what ain’t now broke in favour
of something that different, but if the UI architecture allows for an experimental,
modular/optional implementation, it’d be amazing.

Yes, I brought it up last spring but didn’t really pursue it. I don’t know whether others
have as well.