Fossum 2026 Open Hardware and CAD CAM Dev Room.
Our final presentation when Joe and I were scheduling this thing and we looked at the title
of this presentation and we said, yes, that is a beautiful, beautiful way to finish our
day.
So without further ado, we have Eve who has been an electronics and embedded systems engineer
for about 10 years, mostly in consumer electronics companies, presenting a love letter.
Good evening.
Welcome to the last talk of the day.
So you might wonder why I wanted to give a talk specifically on the ERC if we want to
probably leave favorite feature of Kikada.
So the electrical will check the reason is I've been reviewing some junior and some
other people, Kikada designs and I found a lot of left-over ERC warnings in some designs
or sometimes people use ERC but they wave the one they do not fully understand and I thought
to myself, but ERC is so great, it's a feature that's protecting you against your self and
potential mistakes and maybe we need to explain a little bit more details.
Because people can use it really to it's potential, I won't skip the presentation, it's already
bit dumb, but I just wanted to add that I have been a user of other CAD designs software
tools, so it's a bit interesting, I can compare the little differences between them, I have
been using EagleCAD for one year to start up my career and then I have been mostly using
the Altium for a lot of time.
So we will mostly list a lot of ERC in the series, I hope it can get to finish the session.
But first I will explain a little bit more with my words, what is ERC, try to do a
key to five of my favorite ones, when I really rely upon, I have a little list of the
ERC I always forgot to configure correctly so I wanted to show them, then we'll move on
to a type of ERC that people really, I think they don't really know how to use it correctly,
the pin types and connection matrix ones, they are a little bit more difficult to configure
than the other, and then we will move on to a phone quiz with real life issues I had
and ERC that can help fix them.
So first, the lexricles will check, so there are a lot of sets of heuristics related
to real schematics and at least, it's really, really simple, it just checks if pin in
a component is connected, if it's not it will pop up an error, it checks it's net, has
something it's connected to, otherwise it will pop up an error, and it's a little bit similar
to software warnings or interrupts things like that.
What it is not is a spice simulator or any kind of simulator software.
It has really no absolutely new ideas of what kind of electrical, real electrical things
are happening in new design, it does not know about the equations from the circuits and
whatever, if you need to have these kind of features, you can look at the spice
simulator that's integrated with psychiatry, people are aware of it, as an alternative
to the very, very popular healthy spice simulator, but ERC does not know anything about
electricity, but my is it's important, even if it's not what's going to simulate your
circuit, I'm going to read a quote about warnings, because I've noticed that sometimes
electrical engineering, we're not the best at cleaning up the warnings and the recipe,
we make so, we need to remind people about the things, so most of the times the consequences
for ignoring warnings are nothing, no big deal. However, many of the hard thoughts could have
been found by enabling all compiler warnings and fixing each one, so spend time removing
the seemingly trivial compiler warnings, so you can see the incredibly important ones from
making embedded systems, and the GRC they just work the same. So try to fix as much as you can,
so see if something wrong happened, you will spot it instantly. So this is where I confess my
worst real life mistakes, I have made in my design, bought designer carrier, and this is only
mistakes I have made, and they have been manufactured, and they could have maybe have been avoided
with a bit of checks on your C usage, and then it was made, so I had to live with Tilson
X prototype run, and it cost company money, and everyone was mad, and it's really a bad situation
to be in. So first one is, of course, good old the typo on a net, so it doesn't connect
to the net, maybe it was a dash, and I don't remember exactly the typo, it was a typo.
The result was a microprocessor, was not poured at all, so not pouring up on one of its pins.
We managed to rework for that, but it was not easy fix, so it's a very annoying issue.
The second one is, I just take with the wrong footprint on a peripheral,
this one I could not through work, we could not through work at all, the factory said, sorry,
you just have to remade the whole board, so we had to live without this peripheral for a while,
and the sort of one is a classic TXRX inversion, usually we forget, so first time we
divorced to invert TX and nerex, because the receiver from inside is a transfer from the other side,
but this time I inverted it twice in different pages, and I did not notice that it wasn't
inverted twice, so it was like not inverted, it's not working, very annoying, no debugging, no flashes,
a really bad mess. So there you are, see, in all this lineage, you know, the real
inspect electrical rule checker, it's not dynamic, it needs to be clicked, to be activated,
it won't just run as you go, so don't forget to run it.
You can assign a key shortcut if you want, I used to do it with Altium, here I just
run it manually, but how you prefer it, it took me like years to notice that you can click the
little arrows on the message will appear in the status bar, you can also run it with a command line,
kkcli, which is cheap with kkd will allow you to run the RC, which if you are considering making
a kkcli integration, it's really great, because you can make a kkcli integration board, it's like
we are seeing the light, and if you want to go further on your kk integration, you can use
a software called kk, which make all kind of automations, so this is really great.
Before we talk about the RC themselves, I wanted to remind people about what is the
net least, it's an important concept in the design, because in fact, the PCB editor and
schematics editors are not directly, I mean, a kking to which others are an object between them,
that's the net least, the schematics is going to compile into a net least, with just the list of nets
and the nodes connected to each net, and it's what gets transmitted, so if you want to check it,
you can export it from kkcli in a text format, so you do see what internally kkcli can
understand from your schematics growing here. So top five, RC, so the annotation issues,
RC, it might seem that little bit may, but it's actually really important to make sure that
each one of your components has a good number, only one number, you have the RC that tells you
if you use the same number twice, it's a duplicate item, RC, and another one that will warn you
if you forget to input a number, kkcli should do it automatically, but sometimes you can copy things
and it can go back to not knowing which is its number, it's really bad to let's use errors,
because it could potentially mess up the, it could really make the software not know which component
we are talking about, so they're actually quite bad to have an annotation issue,
to really check the year or see about annotations. This one missing part is in symbols,
I really like because I really like the feature which is to split symbol from a component in several
parts, and then you can have really clean schematics by putting the feature you need in a page and
separate the things you can put the power supply from you as to see in the page, and the
GPIO in as a page, the drawback of it is that if you forget a part of the symbol,
you can put in schli, forget to pour supply a whole chip, or forget really important things,
so that would lead to work at astrophysic and place units, RC is here to make sure that you
had everything you need from your components, a really important one. This one I saw a lot
for a reason, I don't know why some people really like to have different labels on the same
net, in fact it's more annoying that it seems for KK, because KK only keeps one single
name for label in the net list, and then after the schematic spot, it will use the net name in
order to use a feature like a differential pair and the membership, so you have to make sure that
your name makes your differential pair get into the net list, so putting different labels on a
net can really be annoying, there is also a note that if your schematic is a hierarchical,
it will choose the name from the top level, so that's how you make sure that your differential
pairs actually work in KK, so you have to make sure that your top level name is okay.
You have great things I still see sometimes in designs, people tend to think that it's
only graphical, really a little bit messy, but not so bad, but I think it could be really,
bad because in the schematic set it all, your objects need to be exact same coordinates to be
connected, just a little bit of set will not make it connected at all, so you have to make sure
that everything fits into the grid in order to be connected in the software, and if you start having
components, that's a little bit of, you might end up having things that you saw to work
connected and are not connecting at all, so there's an option that can help you align things to
grid, it's called a line items to grid, sometimes you even find of grid things in libraries,
especially if you sometimes I know people use a sub-party libraries that are in porti,
there's an example and you can have a grid component, so you will have to fix them in the grid,
in the lab, of course, don't let any of grids, they can be really, really dangerous.
And of course number one is, you have to see that one's use that something is not connected,
it's really, must use full checker ever. Well, it tells you, if probably you forgot an important
connection, sometimes it's a little bit more difficult to check that the use of the net is not connected.
It can be, well, you have one of those a friend of not connecting issue is the ERC,
that's one of you, if you have loosens, sometimes you just have loosens that just in the
schematic, so they're not really bad they're just ugly, but sometimes it can be because you
forget to connect something, so you'll have a not connecting issue alongside the loose end issue.
My advice is just don't let any loose ends in your designs, it's only a warning, it's only ugly,
but yeah, you have to keep your schematic's ERC messages really clean to make sure
that your schematic's is okay. And then you can have sometimes not connecting issues because you
made a fancy, fancy something that makes an error, especially if you have a hierarchical sheets,
and you forgot to synchronize the sheet and the component in the top level, so something
ends up not connected, but it's not as easy to read and as abuse as just a net that's in the middle
of sheets, so it can, as this is as easy as you can help you spot a potential mistake.
Same with a graphically connected to a burst, but not a member of that burst issue,
it can really help you spot where you have some things that's actually not connected
on top of your not connected issue. And then of course, but I think lots of people are using that
correctly, I did not see anyone having good ups of all this, but there's no connect flag,
it just tells you that this net is not connected, but it's okay, it's how I want it to be not connected.
So you're just waving the ERC for this specific net and it gives you a visual indication,
it's a stamp of approval, that it's okay. So this is a little explanation on how to get
rid of your ERC messages, you don't want to see them anymore, they're annoying and you have to
look under in your seminaries, how to solve them, so you have unrolls of the variable,
this one pops when you put a variable in a text like with a dollar and but you forget to define
a variable in your schematic setups, so you have to add it in your schematic setup or remove the
variable. Again, those are stuff that usually happens to me when I copy past them, I always forget
how to make it right, but you have to fix all those things. Very similar is one with the net class,
you can put it on a schematic class of nets that will say all those nets are 50 ohms and
you can make conditions upon this, but you need to have them defined in your schematic setup
window, so otherwise you will have the ERC that tells you that it's not defined and I get those
not know what to do with it, so we probably have to define them. This one can happen sometimes
when you instantiate the sheet of the, so it's a twice the same sheet that's instantiate it,
because you can know that, it's a really useful feature, but you have to be careful that the
names are different, the names in move, make them different, otherwise it will, it's sort of where
we'll not understand what you're trying to do, so you have to fix this one in sheet properties.
Okay, so I have colleagues that really really love the bus, and I must confess that I'm not
big fan of this particular feature, I think it's quiet, complex to use, not in Cicada and any
software. And it will raise a lot of ERC and when my advice is, we'll be to use them only if you have
a pack of more than four signals, like a really big thing, the ERMI or OctoSPI or GDR, that goes in more
than two places, otherwise you can do it with those other features, something maybe easier to read.
But no, that being said, if you're using the bus, you will have the net, it's graphically
connected to bus, but it's not a member of that bus issue. What generally means that your bus
label syntax is wrong, because bus work with a kind of a rig-exper thing in the bus name,
so you have to write your bus name with a specific syntax, and then all your net names,
match the syntax, otherwise it will be rejected from the bus and not belong to the bus.
So that's what the ERC means.
Sadly, in V9, because we are, I forgot to say, well, I'm more talking about the V9.
There's a little bug, so if you are in the daughter of sheets, the previous ERC does not work,
so you have to be really careful and check your not connected ERC, and remember that it can be
because of the bus. It's not because the bus belonging issue, it's not a bus belonging issue,
so you can also have an invalid connection, bus on the items.
This usually means that you are, again, bus in your hierarchical, and you forget that you have to
copy the bus name to your hierarchical port name. It has to be the same. You cannot invent a new
name as you go along. You have to copy the same, otherwise it will raise the ERC.
In some rare situation, I tried connecting a G&D to a bus, and it also raised this issue,
but I don't know if people actually will do that.
You can have this one. A bus, I'll yes, definition, conflict. It happened to me a lot of time
to be because I moved a sheet around. It means that the bus belonging issue is stored
pairs, schematic file, so if you have one defined in one sheet, another defined in another sheet,
you can end up with the same variable being defined twice in two different files, and it's
annoying, so you have to remove one of those.
This is an ERC I never had. Label connects more than one wires. I wonder how it could happen,
because it's a very weird thing. This one happens only when you put the label hitbox at the
intersection of two wires that are not connected. Global Label not connected,
yes, it's something about global labels. They will trigger an ERC if they're not connected,
but be careful, because poor symbols that are in my mind, they were the same,
then poor and global labels, but they are not. Poor symbols will not trigger an ERC if they are
alone, so be careful about that. It can be a little bit tricky.
So the pin types ERC is something that need to explain a little bit, because I see a lot of people
having doubts about them. There are very scary connection metrics somewhere in the menus.
My reading of this just says that some pin types cannot be connected to other pin types,
and it's generally concerned mostly the outputs. You cannot connect it with another output,
otherwise you'll probably have lots of trouble. So you see this connection metrics that
output and outputs are not compatible and poor outputs and outputs and poor outputs either.
The goal here is to warn you if you're doing something that with your outputs.
You have some special pin types that you can read in the metrics.
Namely, I've seen people use and specified, as specified is weird, because it always gives a warning.
Whatever happens, as we have specified pin types, it's like to do or something that will always
warn. So if you have something that you need to be changed later, you can put it on specified,
otherwise it's just popping ERC, so maybe avoid using it too much.
A no-connect pin can never be connected, but if you have a no-connect actual no-connect pin for a
chip, but you want it connected to something like G&D for mechanical reasons or a net of something,
you can also decide that your pin is free, never once. You can connect a free pin to anything
and can be good for a no-connect pin if you want to have a connection in your way for
your diverse reasons. And passive is the dedicated type of pin for
connectors, passive components, resistance, you name it. You can have the dog for the details of the
user types. I run a popularity contest, because I never know what pin type to choose, so I decided
to organize a vote. And the winner is bidirectional. If you have a GPU in a chip, you put the bidirectional
power input if you're supporting passive and passive and then input and output. So
those names are also scary, but we don't use them as much as bidirectional and poor end.
Okay, so the input, the poor end put pins are a bit special, because they require to be driven.
So an input pin, simple input, not poor end put, can be driven by an output for our put passive
free state or bidirectional. So that's quite wide. And you don't see the poor end put
pin not driven by a new put pins a lot, because you actually have a lot of options.
But the poor end put pins, they need to be driven by a poor end, I would put only. So that's why
you get a lot of this input for a pin not driven by any poor end put pin message. It's a putting
really open. And it means that in the same net you have a poor end put, but you don't have anything
that's flagged as a poor output. So in order to solve this issue, well, there's an issue with this,
because well, in a scenario where my pin is a poor output and my other pin is a poor end put,
or C, checker is really happy, so it does not complain. But if I put something between
input output like a passive or something, it will detect that my poor end put is fed by a passive pin,
so it will raise an error telling me that it's not fed by something that gives a power.
Which is why we have a poor output flag. Which is something you can add maybe not run only,
but where the poor comes from, and it will add a just add a poor output pin on your schematic,
so your C checker will detect that, oh, I have poor, and visually you can see that my poor comes from
somewhere. But then I was never really happy about it, but because I could also forget to
power to feed my poor to my passive components. And it's about then that I thought about
fit and discovered interesting thing, that you can create poor input flag in your library,
if you want to, if you fancy it, it's just a component with a poor input pin. And if you do this,
you will force kicker to check that your connected to another poor output pin, because we
will learn the RC checks, that if there is a poor output pin, you need to fed by a poor output.
So this you close the loop, so it's all it's all checked, you can verify that
your poor goes through all your units. So then I will go back to my real life issues,
and if you want to try to guess what's, which RC will pop, so this is my good old typo,
can somebody scream, what will happen as an RC?
Only one. Oh yeah, it's a whole thing, yeah, there is no VDD for 3.3, the rest of the
schematics. I'm connected that label. Yeah, it's an unconnected thing, of course it detects
the unconnection. So, but it's not what's happened, it was too easy. What happened is that
I had a deep coupling capacitor, so it was actually connected to something. So the unconnected label
did not work in my case, it was an alternative, but we haven't connected, we had the unconnected
label too. And now, which RC could, label connected to a single net?
No, it won't raise. Yes, it's a poor one, yeah, because VDD and VDDA and VBAT are flagged as poor inputs,
so KKD will actually detect that it's not connected to bar output, because my capacitor is actually
a passive pin, so it's not driving any power, so this time it will raise a new RC that could
have saved me from making mistakes. And there is a fencing, I do not know it existed, but in this
situation, can you think another RC, so the type was changed, the type of is not capital V versus
smaller, small V.
Yeah, it's a detection from the case sensitivity. If you just have the same name twice, but it's
the case that change, it will suspect that something is actually wrong. So only for the case,
K things, but it will detect the K things, that's not so bad, okay.
So yeah, I present to QFN48, and I present to QFN48, but not the same.
So classic trap, QFNPich can be different, there's a lot of QFNPich is actually, you have to read
the datasheet carefully, but you can also if you fancy it, use a feature, niche feature or
your C of KKD, if you have to help you, it's not solving the problem 100%. Yes, for print filter.
So yeah, you have a feature that's called the print filter, you put it in your
component, it's a simplified regex, don't worry, it's not the full regex thing with all the,
we are the symbol, it's only stars and question marks, you put a footprint filter in your
library, and then it will raise warning if you, the footprint you chose does not match the
filter. By default, it's disabled, you have to enable it, and then you have to make sure that
your prints respect a certain type of rules on how it's defined, you can find a proposition
of rules in the KKD library rules. So yeah, you can see in the examples that here's the
filter is catching a pitch 0.5 and the footprint has a matching pitch 0.5. So it might help you
not mess up the QFN pitch, if you decide to configure it. And last ERC in a real life,
so good old TX and ErX inversion. So you have different variants to make that up.
But there's actually a new ERC, I found that could help, and there's certain conditions.
Well, multiple outputs from the same net. Almost, you can, but it won't pop in this exact
situation. Well, what you can do, well, first of all, you can rename your TX and ErX to something
that describes the absolute direction of where your net is going, very far too, and you can
shoot it very far. I like this option. You can use it. It's really great. But if you want to do it
so-to-re-way, you can also decide that your pin is an output, and if you remember in the
connection matrix, output cannot be connected to outputs. It raises an ERC. So if you decide that
your pin is an output, either by putting in library or using the I create little flag that
has an output pin in my library, you can decide to flag something as an output, and then you won't
be able to connect your TX with another TX, otherwise it will be, oh, you're connecting output together,
it's not really normal. So yeah, and this, for example, it's quite obvious because it's on the same
page, but if you have a design where you have a lot of TX and ErX everywhere on the fitting different
pages, it can be quite useful to have an automated checks for that. But there's an even better
option that it's a new feature. I did not notice it up until recently, but there's a feature in v9,
where you can have a drop down menu and choose the different options for your pins,
because your GPUs, you can choose if your PB6, you want it to be a user TX, and it's not only the
name of the pin, it's also the pin type of the pin, so TX, you can decide it's an output,
PB5 will be a bidirectional, of course, and the user TX will be an output, and if you do this with all
of your pins, they will naturally be output and collide with other outputs, making the check for
a TX and ErX complete. So, as a conclusion, just use the RC, use the maximum RC, everything you
can, clean up the noise, of course. If you can have a sound about your mistakes and also people
mistakes to try. Try to improve your process, and something that's well, we have to remind
that first them, but electrical engineering are not in the habit of using open source lots,
so we have to remind that this time it's not just a vertical option that gives you things
and you say, okay, you can participate in having puts in, okay, so take the opportunity,
if you can, okay, so it's a reference page, but thank you, and if you have any questions.
If you could add one ERC check to keep had what would it be?
I would have lots of your checks, but I don't know if you see people, so I think I would have more
typo checkers, because I have lots of, I do a lot of typos, so I have more things that should
be enabled by default, so some of these checks are turned off by default, maybe we should just
turn them on, would that be better? Well, it's complicated, because they're done up by default for a
good reason. You have one checks that checks a graphical thing, the checks that nets are crossed,
but it's only a visual indication, because it can be legit that you put cross nets in your
scheme, it depends on how you're working and your type of designs, maybe, and a lot of people
they won't do as much a process as we do in digital, but yeah, turn off, if what's one by default,
in turn off, well, the one turned on by default are quiet, I think it's not default options are
quite legit, the football filter is of by default, because you might want to use or
partly libraries, and it will just be impossible to make it right easily, so it's
so-so-ish made that it's of by default, it would just pop too much noise, but yeah, no, I'm quite happy
with the default options. What's your view on this power flag solution? Because at some time,
in my, yeah, I got this, yeah, I've seen multiple times, and each time, I'm like, yeah, am I
really enhancing my schematic by placing these symbols, or I'm just adding more visibility burden,
I'm like, yeah, I usually dismiss this errors. I understand your, I would love to have it
a bit like a net least, or something you can write click and say, okay, this is an output,
or something that is not necessarily shown as a schematic, because I can be hidden as a symbol,
but are you clicked somewhere in order to make them pop, but not having them by default,
because otherwise it's really annoying. Well, you don't need the flag if it's in your symbol,
but it would not be legitimate to have like pouring, putting or and pour out, put in a resistance.
So, I don't know if there's a better option than adding flags, and it's kind of a habit that we do that
in schematic design. It's, it's always difficult because it's kind of a tradeoff between
drawing something that can be read and drawing something that isn't appropriate by software.
So, yeah, those of like ideas, yeah, perfect, but I don't have any idea on how we could do
something much, much better, the point. So, we work on the kick out libraries, and like several
of your slides where there's no, oh wow, we've never seen anything like this before, this is amazing.
So, other than having a power input flag, which we'll definitely be doing, what else would you
like to see in the like changes in the libraries that would make things better?
So, there's only a lot of work on the library. Ideally, I think the MCUs are not split enough.
If I was to use a big, big, big MCU, I think I would do a schematic's different library
symbol in order to have more splits, but it's hard to know without knowing what type of design you
will make because maybe some people will like to have a one-pager and other people will like to
split things on five pages. So, and also I think for now the options, when you can select
the different pins from GPIOs, for those there will be directional. So, if we could have the
right, maybe enforce, I don't know if it's possible or if it would raise too much trouble to have
them as outputs and inputs instead of bidirectional, but it would be maybe a good thing to have.
Thank you for the presentation. When you're working with a lot of people, because the way I see it's
setting up ERC and setting up the symbol, setting up which port does what and so on. So, of course,
they can become a point when it is very specific to the project itself. So, when you're working with
other people and you want people to review your design or if you're sharing the project via GitHub,
how do you approach this thing about telling people, hey, look, run the ERC and if you're
forking this, this is the ERC setup that we have used or if you want to contribute, please do not
ignore this type of ERC warnings. How do you approach that problem where you can very quickly
hyper-specify the ERC and then the people you're working with might not necessarily be looking
to the same errors as you are. So, it's a work. I think most of the set-ups are in the
schematics, in the kayak designs, that not a lot of, yeah, I do have a little bit of tricks with
poor flags and paint type flags, but that's all I ever did, I don't have so many
custom things for now, it's same you are, see about for everyone. And as I say, I like the default
options of kayak, so I'm not changing a lot, upon that. But yeah, you can, yeah,
it can be a niche because a lot of the ERC are ignored because of, they can be, and cannot
be enforced because of typically sub-party libraries and then a lot in an open-out where you
just pull a library that's not from the kayak library and they put less care into making
sure everything works with the kayak system, most of them they export to different cats software.
So, you have to waive a little bit of the ERC, especially the Pintypes ERC because it does not work the
same, but that's the only big difference I see between design. It's most of the time it will be okay,
I guess. And in a way, your ERC setup will be saved with your project, so you know what's happening.
All right, thank you very much. Thanks everyone for joining us today. That's it for the Open
Hardware Cat Cam Devroom. There's still one last set of presentations over in Jansson to wrap up
Fossdom 26. So, thanks everyone, safe travels as you head back home.