What follows is a rather harsh criticism on KiCad – a freeware PCB CAD.
I should probably start from stating the fact that I have some system analysis background and I have been popularizing Linux more than 20 years. I only avoid stating “M$ is evil” because several of my former and current employers list M$ as a valuable partner. This way, it seems, I shouldn’t have anything against free software. And indeed, for me, KiCad seems rather usable, at least for certain kind of projects. I have seen and used Eagle (for hobby, not for earning), I calmly ignore eventual GUI glitches (that Mac gays so hate) and I am silently able to find text files deep in /usr/share/kicad/whatever/ and edit them by vi. But.
A well known problem with KiCad is the so called hidden pins feature. That functionality of KiCad has been largely criticized by many experts (e.g. http://transistorgrab.de/2016/02/05/why-hidden-pins-are-evil-and-nets-should-only-have-one-name/ ) throughout the years and, it still has been ignored by ppl behind the KiCad development to the same extent. It seems to be a religious or ideological issue that nobody wants to touch or change. My today’s goal is to join the game and affect the balance in my way.
To somewhat comply with the good traditions of bug hunting, let’s be more precise about our object of hate:
I looked for the KiCad wit a particular task in mind – to design and build an old-fashioned LPT breakout board for a DIY CNC. Seems an innocent goal. I was in age 16 or 17 when I manually (on paper) routed my first “large” digital design (some 37 CMOS logic chips of Russian К172 series). The pecularities of and breakout board are – a) two separated power chains/contours (both 5V but galvanically separated by optocouplers); b) the galvanically separated (from each other) grounds. Saying it short – the electrical safety.
I installed KiCad on my Ubuntu Linux; that was rather simple, although required first upgrading Ubuntu to version 16.04. Googling for KiCad made it extremely evident – there shall be problems in case you wish to design anything involving somewhat complex power lines. I took the risk.
Currently, having spent two full days investigating the issue, I have to offer two important deliverables – first, a tutorial to manage two (or more) power contours in KiCad. The other deliverable is pinpointing an extremely annoying bug that underlines what numerous people have said throughout the years – KiCad hidden power lines feature REALLY suxx. Many thanks to the authors behind kikadhowto.wikidot.com to still explain that specific issue along the numerous articles.
The WARNING – should you want to avoid the problems (both with KiCad and with its maintainers), if EVER designing anything with multiple power lines or ESPECIALLY with multiple ground lines, DO SWITCH OFF the KiCad hidden pin feature. Should you ignore the warning, your PCB designs could silently circumvent electrical safety rules and, as the worst case result, could kill a human being (or more).
A fast workaround – do edit your libraries (all of those; one by one, manually, by Part Library Editor, at least for 2 pins per IC) and mark the power lines as visible. Your design gets a little bit more cluttered but you’ll then never meet those horrible KiCad bugs. The downside is – you cannot anymore use the libraries distributed centrally, because from now, from your standpoint, these are plagued by the “hidden pin” ideology. And from now, be prepared for a lot of manual work serving the ideological gap.
Two Power Contours Tutorial
We use KiCad to compile the following schematics:
There are two fully separated power contours. To stay within the standard possibilities of the KiCad, the labels “+5VA” and “GNDA” are used for the first contour and “+5VD” with “GNDD” for the other. Semioticists will not like these labels – should be +5VA, +5VB, +5VC etc – not plus five digital and analog, but that is a minor nuisance. As seen on the above picture, the Electrical Rules Check (ERC) is yelling and has issued four errors (do you see these four arrow?). So far so good.
The KiCad concept for “stop yelling, you stupid, I haven’t yet connected my battery” is the “PWR_FLG”. You should put that “Don’t Yell” sign to each unhappy power line/net. Let’s start from the first:
The miracle happened – one warning out of four has gone, three remained. Let’s do the same three more times – do put “Don’t Yell” signs to silence the remaining ERC arrows:
Done, no ERC warnings anymore.
Now, let’s start placing some IC’s on the schematics sheet. It is a little known secret, that in the KiCad 74xx digital library, standard power pins (mostly 7 and 14) are “hidden”. In case you don’t believe, do launch the Part Library Editor or Part Library Browser, and pay attention what is written near pins 7 and 14 – respectively GND and VCC, which, in the essence, are some extra labels one could add to the existing wires (well, actually nets). It is very evident that there is still no VCC and GND present everywhere on our schematics, so let’s put these there before ERC starts yelling. These symbols are obtainable from the “power” library.
ERC now has no complaints anymore.
However, things will start getting complicated. Imagine, there should be another chip in our design that should suck its power from PowerB connector (do you remember – galvanical separation!). How to achieve that? In case of KiCAD, the answer is deeply sad. The easy part is to put labels like e.g. VDD and GNDD onto the second power countour. GNDD actually is already there (we can add another more cryptic label at any time), thus let’s add the VDD label:
Now the tough part. The standard 74xx library is not suitable anymore. Why? Because its hidden pins are described as “VCC and GND” but we currently need “VDD and GNDD” labels on the power lines. Let’s open the Part Library Editor. Our task is: a) do open 74xx lib as the current library, b) do import some IC from there, our choice is 74HCT04; c) do changethe component with the graphical editor and rename the hidden pins – both!; and d) do save/export the changed part to some extra library.
I have shifted/”moved” one of the grey labels a bit off, because a) otherwise the labels tend to mutually shadow themselves and become unreadable, especially if longer; b) I wanted to have a clear telltale sign that we are dealing with the modified library:
In addition to that, because Kicad won’t discover libraries automagically, we have to somehow communicate it to the KiCad that we have created a perverse extra IC library for the second power contour. Let’s try to analyze the situation and grasp the deeper meaning of it! Is that indeed what libraries initially were intended for?
However, let’s put our religious opinions aside and continue the work. To be extremely sure nobody has changed our reality (BTW, I am a big fan of the Matrix), we will launch the Part Library Browser and double check that our component really is what we wish to have:
It is. It’s time now to put that component onto the shematics sheet.
To understand it better, what would happen if we DO NOT add the label “VDD” to the power contour? That’s the classics:
But we prepared ourselves. We took notice that our perverse library has VDD and GNDD defined as the power pins (who did? We ourselves did!), and we also added the VDD label to the power contour (in case of GNDD, the “connectivity” appeared automagically, as the main feature of the hidden power pins, thus no second arrow pinpointing the GNDD).
However, being a little bit paranoid, I mapped the components to modules, imported the Netlist into the PcbNew Editor and manually solved the ratnet (against the visibility criteria). Indeed, we can see two power contours with NO connectivity inbetween:
One could draw the nice red line of the galvanic separation. And this is actually the end of the tutorial. Now you know how to do that (although, as you see below, better do stay apart from KiCad while designing safety critical devices).
So far so good. To confess a sin, until this point, we intentionally made a simplification to carefully avoid the real trap with KiCad. Now let’s see what the real trap is. Our aim – provided we already have two galvanically separated power contours, let’s make a practical use of these. Let’s use digital logic IC’s on the both sides, as it should be in a real design. To start from an innocent example, let’s build something like that:
There is no visible problem with the design. The ERC remains silent about the above schematics.
However, the problems start as soon as we try to use the same type of the IC on both sides (i.e. one IC powered from PowerA, another from PowerB). Let’s kick out that optocoupler and substitute it for an 74HCT04 chip. (An important secret is that 7414 and 7404 actually are aliases in KiCad library 74xx. We’ll later see why this bloody fact occurs to be important. What we do here, is, a) we open the unmodified 74xx library with VCC and GND pins intact, b) we place the 74HC04 chip into the upper leg of our design (i.e. the leg powered from PowerA):
Done as told. But hey, what happened now?! The component that we just took from the original 74xx library, is playing jokes with us. It’s pinout is not anymore what we inspected in 74xx library. The component has changed:
To be very precise, the 74xx library is still intact (one can inspect it once again, it has pins 7 and 14 lined up and hidden power lines are marked as VCC and GND).
But as soon as we put that component on the sheet, it gets momentarily poisoned by our perverse library lib/X_74hct04 and by the pinout there. Why!
However, let’s see, what ERC tells us about our design:
ERC is fully satisfied with our design. What actually happened, is that while designing a safety oriented device (remember – galvanically separated power contours!) Kicad enforced it’s deficient logic and transformed the design into something that either is not working or is violating the safety rules. In fact, my design was silently changed and overridden by a memetic bug acting on the background and as a result, both the components U2 and U3 are now powering themselves from the PowerB source.
One of the main issues is that the unsuspicious user has no idea what the damned robot did with its U2 and U3 power lines. We do know now, because we have spent two days investigating the KiCad covert behaviour:
This is U3 that we took from the original 74xx library and that was meanwhile transformed…
This is how the actual pinout of the chip looks like in 74xx library.
The truth as I see it today, is that the underlying logic in KiCad suxx in a way which is dangerous safety wise, both for people and their designs. We can guess how it happens – the name of the component is the same in both libraries. Now you understand why I specifically chose different chips for different legs – 7414 vs 7404. It is a brilliant showcase how dangerous could careless aliasing be. But aliasing is a lesser sin.
It seems, there exist a serious naming space problem in KiCad – a component explicitly taken from a library should not, I REPEAT, SHOULD NOT, covertly change it’s pinout and/or defy the electrical safety precautions of a design. Honestly said, I am not particularly interested about it, what kind of brilliant religious ideas the authors and maintainers had in their heads. KiCad’s underlying philosophy related to the hidden power pins is inheritly dangerous and can, in worst cases, lead to the loss of the human life. F yourself, guys!
Speaking about FOSS ideology, I see at least two major glitches here. First, the meme “every serious user maintains his own libraries” is inheritly wrong, it seriously limits the maximum achievable quality of the software. And then, FOSS traditionally had more balls … remember Linus and the occasions he made the kernel incompatible again. The goal of keeping the ideological idiosyncrasies for “not breaking” previous designs … it more remembers me the corporate than free software culture.
I am now thinking what should be the practical steps to hack the KiCad to force it behave as I want. Much likely I have to manually edit the extra library, to erase all aliases from there and might be it’s even necessary to change the 74HC14 name to somewhat else, e.g. “My_secret_KiCad_IC”. Please have a thought about the situation and try to understand the deeper meaning! Is this indeed what libraries initially were meant for? Don’t I remember it correctly the libraries were once created to ease the life not as a convenient workaround vehicle to hide workarounds to the bugs, do I?!
For the KiCad maintainers – should the component name indeed be hierarchically higher than the library name it was taken from?