WEBVTT 00:00.000 --> 00:09.720 Fossum 2026 Open Hardware and CAD CAM Dev Room. 00:09.720 --> 00:13.280 Our final presentation when Joe and I were scheduling this thing and we looked at the title 00:13.280 --> 00:18.920 of this presentation and we said, yes, that is a beautiful, beautiful way to finish our 00:18.920 --> 00:19.920 day. 00:19.920 --> 00:25.880 So without further ado, we have Eve who has been an electronics and embedded systems engineer 00:25.880 --> 00:31.560 for about 10 years, mostly in consumer electronics companies, presenting a love letter. 00:31.560 --> 00:33.360 Good evening. 00:33.360 --> 00:37.560 Welcome to the last talk of the day. 00:37.560 --> 00:44.400 So you might wonder why I wanted to give a talk specifically on the ERC if we want to 00:44.400 --> 00:49.160 probably leave favorite feature of Kikada. 00:49.160 --> 00:55.160 So the electrical will check the reason is I've been reviewing some junior and some 00:55.160 --> 01:04.360 other people, Kikada designs and I found a lot of left-over ERC warnings in some designs 01:04.360 --> 01:12.920 or sometimes people use ERC but they wave the one they do not fully understand and I thought 01:12.920 --> 01:19.600 to myself, but ERC is so great, it's a feature that's protecting you against your self and 01:19.600 --> 01:25.120 potential mistakes and maybe we need to explain a little bit more details. 01:25.120 --> 01:32.680 Because people can use it really to it's potential, I won't skip the presentation, it's already 01:32.680 --> 01:38.320 bit dumb, but I just wanted to add that I have been a user of other CAD designs software 01:38.320 --> 01:44.240 tools, so it's a bit interesting, I can compare the little differences between them, I have 01:44.240 --> 01:49.980 been using EagleCAD for one year to start up my career and then I have been mostly using 01:50.020 --> 01:55.740 the Altium for a lot of time. 01:55.740 --> 02:03.420 So we will mostly list a lot of ERC in the series, I hope it can get to finish the session. 02:03.420 --> 02:13.020 But first I will explain a little bit more with my words, what is ERC, try to do a 02:13.020 --> 02:21.960 key to five of my favorite ones, when I really rely upon, I have a little list of the 02:21.960 --> 02:30.940 ERC I always forgot to configure correctly so I wanted to show them, then we'll move on 02:30.940 --> 02:39.740 to a type of ERC that people really, I think they don't really know how to use it correctly, 02:39.740 --> 02:44.700 the pin types and connection matrix ones, they are a little bit more difficult to configure 02:44.700 --> 02:53.660 than the other, and then we will move on to a phone quiz with real life issues I had 02:53.660 --> 02:57.860 and ERC that can help fix them. 02:57.860 --> 03:02.540 So first, the lexricles will check, so there are a lot of sets of heuristics related 03:02.540 --> 03:08.580 to real schematics and at least, it's really, really simple, it just checks if pin in 03:08.580 --> 03:14.820 a component is connected, if it's not it will pop up an error, it checks it's net, has 03:14.820 --> 03:19.740 something it's connected to, otherwise it will pop up an error, and it's a little bit similar 03:19.740 --> 03:24.780 to software warnings or interrupts things like that. 03:24.780 --> 03:30.380 What it is not is a spice simulator or any kind of simulator software. 03:30.380 --> 03:36.820 It has really no absolutely new ideas of what kind of electrical, real electrical things 03:36.900 --> 03:44.900 are happening in new design, it does not know about the equations from the circuits and 03:44.900 --> 03:49.860 whatever, if you need to have these kind of features, you can look at the spice 03:49.860 --> 03:57.620 simulator that's integrated with psychiatry, people are aware of it, as an alternative 03:57.620 --> 04:02.980 to the very, very popular healthy spice simulator, but ERC does not know anything about 04:03.900 --> 04:11.140 electricity, but my is it's important, even if it's not what's going to simulate your 04:11.140 --> 04:16.900 circuit, I'm going to read a quote about warnings, because I've noticed that sometimes 04:16.900 --> 04:22.580 electrical engineering, we're not the best at cleaning up the warnings and the recipe, 04:22.580 --> 04:28.740 we make so, we need to remind people about the things, so most of the times the consequences 04:28.740 --> 04:34.020 for ignoring warnings are nothing, no big deal. However, many of the hard thoughts could have 04:34.020 --> 04:39.700 been found by enabling all compiler warnings and fixing each one, so spend time removing 04:39.700 --> 04:46.260 the seemingly trivial compiler warnings, so you can see the incredibly important ones from 04:46.260 --> 04:53.860 making embedded systems, and the GRC they just work the same. So try to fix as much as you can, 04:53.860 --> 05:03.220 so see if something wrong happened, you will spot it instantly. So this is where I confess my 05:03.220 --> 05:10.020 worst real life mistakes, I have made in my design, bought designer carrier, and this is only 05:10.020 --> 05:17.220 mistakes I have made, and they have been manufactured, and they could have maybe have been avoided 05:17.220 --> 05:25.300 with a bit of checks on your C usage, and then it was made, so I had to live with Tilson 05:25.300 --> 05:30.260 X prototype run, and it cost company money, and everyone was mad, and it's really a bad situation 05:30.260 --> 05:38.900 to be in. So first one is, of course, good old the typo on a net, so it doesn't connect 05:38.900 --> 05:46.580 to the net, maybe it was a dash, and I don't remember exactly the typo, it was a typo. 05:46.580 --> 05:54.180 The result was a microprocessor, was not poured at all, so not pouring up on one of its pins. 05:56.180 --> 06:02.900 We managed to rework for that, but it was not easy fix, so it's a very annoying issue. 06:03.620 --> 06:07.780 The second one is, I just take with the wrong footprint on a peripheral, 06:10.500 --> 06:15.140 this one I could not through work, we could not through work at all, the factory said, sorry, 06:16.020 --> 06:21.860 you just have to remade the whole board, so we had to live without this peripheral for a while, 06:22.580 --> 06:28.980 and the sort of one is a classic TXRX inversion, usually we forget, so first time we 06:28.980 --> 06:35.380 divorced to invert TX and nerex, because the receiver from inside is a transfer from the other side, 06:35.380 --> 06:41.220 but this time I inverted it twice in different pages, and I did not notice that it wasn't 06:41.220 --> 06:47.940 inverted twice, so it was like not inverted, it's not working, very annoying, no debugging, no flashes, 06:49.140 --> 06:56.020 a really bad mess. So there you are, see, in all this lineage, you know, the real 06:56.020 --> 07:01.620 inspect electrical rule checker, it's not dynamic, it needs to be clicked, to be activated, 07:01.620 --> 07:08.100 it won't just run as you go, so don't forget to run it. 07:09.060 --> 07:14.820 You can assign a key shortcut if you want, I used to do it with Altium, here I just 07:14.820 --> 07:23.060 run it manually, but how you prefer it, it took me like years to notice that you can click the 07:23.060 --> 07:32.340 little arrows on the message will appear in the status bar, you can also run it with a command line, 07:33.300 --> 07:40.740 kkcli, which is cheap with kkd will allow you to run the RC, which if you are considering making 07:40.740 --> 07:46.740 a kkcli integration, it's really great, because you can make a kkcli integration board, it's like 07:46.740 --> 07:53.700 we are seeing the light, and if you want to go further on your kk integration, you can use 07:53.780 --> 07:59.380 a software called kk, which make all kind of automations, so this is really great. 08:02.020 --> 08:07.780 Before we talk about the RC themselves, I wanted to remind people about what is the 08:07.780 --> 08:13.540 net least, it's an important concept in the design, because in fact, the PCB editor and 08:13.540 --> 08:19.780 schematics editors are not directly, I mean, a kking to which others are an object between them, 08:19.780 --> 08:25.300 that's the net least, the schematics is going to compile into a net least, with just the list of nets 08:25.300 --> 08:33.220 and the nodes connected to each net, and it's what gets transmitted, so if you want to check it, 08:33.220 --> 08:38.580 you can export it from kkcli in a text format, so you do see what internally kkcli can 08:38.660 --> 08:51.060 understand from your schematics growing here. So top five, RC, so the annotation issues, 08:51.060 --> 08:57.060 RC, it might seem that little bit may, but it's actually really important to make sure that 08:57.060 --> 09:07.700 each one of your components has a good number, only one number, you have the RC that tells you 09:07.780 --> 09:14.100 if you use the same number twice, it's a duplicate item, RC, and another one that will warn you 09:14.100 --> 09:20.580 if you forget to input a number, kkcli should do it automatically, but sometimes you can copy things 09:20.580 --> 09:27.220 and it can go back to not knowing which is its number, it's really bad to let's use errors, 09:27.220 --> 09:35.060 because it could potentially mess up the, it could really make the software not know which component 09:35.140 --> 09:40.260 we are talking about, so they're actually quite bad to have an annotation issue, 09:40.260 --> 09:47.860 to really check the year or see about annotations. This one missing part is in symbols, 09:47.860 --> 09:55.620 I really like because I really like the feature which is to split symbol from a component in several 09:55.620 --> 10:03.300 parts, and then you can have really clean schematics by putting the feature you need in a page and 10:03.380 --> 10:09.220 separate the things you can put the power supply from you as to see in the page, and the 10:09.220 --> 10:17.860 GPIO in as a page, the drawback of it is that if you forget a part of the symbol, 10:18.900 --> 10:26.580 you can put in schli, forget to pour supply a whole chip, or forget really important things, 10:26.580 --> 10:33.140 so that would lead to work at astrophysic and place units, RC is here to make sure that you 10:33.140 --> 10:42.500 had everything you need from your components, a really important one. This one I saw a lot 10:42.500 --> 10:49.780 for a reason, I don't know why some people really like to have different labels on the same 10:50.100 --> 10:59.860 net, in fact it's more annoying that it seems for KK, because KK only keeps one single 10:59.860 --> 11:10.660 name for label in the net list, and then after the schematic spot, it will use the net name in 11:10.660 --> 11:17.540 order to use a feature like a differential pair and the membership, so you have to make sure that 11:18.500 --> 11:27.140 your name makes your differential pair get into the net list, so putting different labels on a 11:27.140 --> 11:35.140 net can really be annoying, there is also a note that if your schematic is a hierarchical, 11:35.140 --> 11:41.060 it will choose the name from the top level, so that's how you make sure that your differential 11:41.140 --> 11:48.660 pairs actually work in KK, so you have to make sure that your top level name is okay. 11:52.820 --> 12:01.620 You have great things I still see sometimes in designs, people tend to think that it's 12:01.620 --> 12:08.580 only graphical, really a little bit messy, but not so bad, but I think it could be really, 12:08.900 --> 12:14.660 bad because in the schematic set it all, your objects need to be exact same coordinates to be 12:14.660 --> 12:21.940 connected, just a little bit of set will not make it connected at all, so you have to make sure 12:21.940 --> 12:29.940 that everything fits into the grid in order to be connected in the software, and if you start having 12:29.940 --> 12:35.780 components, that's a little bit of, you might end up having things that you saw to work 12:35.780 --> 12:41.860 connected and are not connecting at all, so there's an option that can help you align things to 12:41.860 --> 12:49.140 grid, it's called a line items to grid, sometimes you even find of grid things in libraries, 12:49.940 --> 12:55.140 especially if you sometimes I know people use a sub-party libraries that are in porti, 12:55.140 --> 13:00.900 there's an example and you can have a grid component, so you will have to fix them in the grid, 13:01.860 --> 13:07.060 in the lab, of course, don't let any of grids, they can be really, really dangerous. 13:08.660 --> 13:12.580 And of course number one is, you have to see that one's use that something is not connected, 13:13.300 --> 13:25.220 it's really, must use full checker ever. Well, it tells you, if probably you forgot an important 13:25.460 --> 13:34.100 connection, sometimes it's a little bit more difficult to check that the use of the net is not connected. 13:36.980 --> 13:45.540 It can be, well, you have one of those a friend of not connecting issue is the ERC, 13:45.540 --> 13:50.660 that's one of you, if you have loosens, sometimes you just have loosens that just in the 13:50.660 --> 13:56.500 schematic, so they're not really bad they're just ugly, but sometimes it can be because you 13:56.500 --> 14:02.740 forget to connect something, so you'll have a not connecting issue alongside the loose end issue. 14:04.260 --> 14:11.140 My advice is just don't let any loose ends in your designs, it's only a warning, it's only ugly, 14:11.140 --> 14:18.820 but yeah, you have to keep your schematic's ERC messages really clean to make sure 14:19.780 --> 14:27.700 that your schematic's is okay. And then you can have sometimes not connecting issues because you 14:27.700 --> 14:37.460 made a fancy, fancy something that makes an error, especially if you have a hierarchical sheets, 14:38.100 --> 14:44.980 and you forgot to synchronize the sheet and the component in the top level, so something 14:44.980 --> 14:52.500 ends up not connected, but it's not as easy to read and as abuse as just a net that's in the middle 14:52.500 --> 15:00.180 of sheets, so it can, as this is as easy as you can help you spot a potential mistake. 15:01.300 --> 15:06.340 Same with a graphically connected to a burst, but not a member of that burst issue, 15:06.900 --> 15:12.260 it can really help you spot where you have some things that's actually not connected 15:12.900 --> 15:22.820 on top of your not connected issue. And then of course, but I think lots of people are using that 15:22.820 --> 15:29.700 correctly, I did not see anyone having good ups of all this, but there's no connect flag, 15:29.700 --> 15:36.020 it just tells you that this net is not connected, but it's okay, it's how I want it to be not connected. 15:36.100 --> 15:42.740 So you're just waving the ERC for this specific net and it gives you a visual indication, 15:42.740 --> 15:53.620 it's a stamp of approval, that it's okay. So this is a little explanation on how to get 15:53.620 --> 15:59.860 rid of your ERC messages, you don't want to see them anymore, they're annoying and you have to 16:00.740 --> 16:05.860 look under in your seminaries, how to solve them, so you have unrolls of the variable, 16:05.860 --> 16:13.300 this one pops when you put a variable in a text like with a dollar and but you forget to define 16:13.300 --> 16:20.020 a variable in your schematic setups, so you have to add it in your schematic setup or remove the 16:20.020 --> 16:25.620 variable. Again, those are stuff that usually happens to me when I copy past them, I always forget 16:25.620 --> 16:34.660 how to make it right, but you have to fix all those things. Very similar is one with the net class, 16:34.660 --> 16:40.580 you can put it on a schematic class of nets that will say all those nets are 50 ohms and 16:41.780 --> 16:48.820 you can make conditions upon this, but you need to have them defined in your schematic setup 16:48.820 --> 16:54.020 window, so otherwise you will have the ERC that tells you that it's not defined and I get those 16:54.020 --> 17:02.420 not know what to do with it, so we probably have to define them. This one can happen sometimes 17:02.420 --> 17:09.300 when you instantiate the sheet of the, so it's a twice the same sheet that's instantiate it, 17:09.300 --> 17:14.020 because you can know that, it's a really useful feature, but you have to be careful that the 17:14.020 --> 17:21.060 names are different, the names in move, make them different, otherwise it will, it's sort of where 17:21.220 --> 17:26.500 we'll not understand what you're trying to do, so you have to fix this one in sheet properties. 17:29.060 --> 17:34.020 Okay, so I have colleagues that really really love the bus, and I must confess that I'm not 17:34.660 --> 17:41.860 big fan of this particular feature, I think it's quiet, complex to use, not in Cicada and any 17:41.860 --> 17:50.260 software. And it will raise a lot of ERC and when my advice is, we'll be to use them only if you have 17:50.740 --> 17:59.300 a pack of more than four signals, like a really big thing, the ERMI or OctoSPI or GDR, that goes in more 17:59.300 --> 18:07.140 than two places, otherwise you can do it with those other features, something maybe easier to read. 18:07.140 --> 18:13.780 But no, that being said, if you're using the bus, you will have the net, it's graphically 18:13.860 --> 18:20.660 connected to bus, but it's not a member of that bus issue. What generally means that your bus 18:20.660 --> 18:27.060 label syntax is wrong, because bus work with a kind of a rig-exper thing in the bus name, 18:27.060 --> 18:34.420 so you have to write your bus name with a specific syntax, and then all your net names, 18:34.420 --> 18:42.420 match the syntax, otherwise it will be rejected from the bus and not belong to the bus. 18:42.420 --> 18:46.900 So that's what the ERC means. 18:49.060 --> 18:53.140 Sadly, in V9, because we are, I forgot to say, well, I'm more talking about the V9. 18:54.260 --> 18:58.980 There's a little bug, so if you are in the daughter of sheets, the previous ERC does not work, 18:58.980 --> 19:04.820 so you have to be really careful and check your not connected ERC, and remember that it can be 19:04.820 --> 19:13.460 because of the bus. It's not because the bus belonging issue, it's not a bus belonging issue, 19:13.460 --> 19:19.860 so you can also have an invalid connection, bus on the items. 19:21.140 --> 19:27.460 This usually means that you are, again, bus in your hierarchical, and you forget that you have to 19:27.460 --> 19:33.140 copy the bus name to your hierarchical port name. It has to be the same. You cannot invent a new 19:34.100 --> 19:38.980 name as you go along. You have to copy the same, otherwise it will raise the ERC. 19:40.740 --> 19:46.820 In some rare situation, I tried connecting a G&D to a bus, and it also raised this issue, 19:46.820 --> 19:50.580 but I don't know if people actually will do that. 19:52.820 --> 19:57.860 You can have this one. A bus, I'll yes, definition, conflict. It happened to me a lot of time 19:57.860 --> 20:07.140 to be because I moved a sheet around. It means that the bus belonging issue is stored 20:07.140 --> 20:13.700 pairs, schematic file, so if you have one defined in one sheet, another defined in another sheet, 20:13.700 --> 20:18.580 you can end up with the same variable being defined twice in two different files, and it's 20:19.140 --> 20:21.300 annoying, so you have to remove one of those. 20:21.380 --> 20:35.860 This is an ERC I never had. Label connects more than one wires. I wonder how it could happen, 20:35.860 --> 20:44.180 because it's a very weird thing. This one happens only when you put the label hitbox at the 20:44.180 --> 20:56.180 intersection of two wires that are not connected. Global Label not connected, 20:57.460 --> 21:05.060 yes, it's something about global labels. They will trigger an ERC if they're not connected, 21:05.060 --> 21:11.460 but be careful, because poor symbols that are in my mind, they were the same, 21:11.460 --> 21:18.340 then poor and global labels, but they are not. Poor symbols will not trigger an ERC if they are 21:18.340 --> 21:21.700 alone, so be careful about that. It can be a little bit tricky. 21:24.100 --> 21:33.060 So the pin types ERC is something that need to explain a little bit, because I see a lot of people 21:33.060 --> 21:38.820 having doubts about them. There are very scary connection metrics somewhere in the menus. 21:38.820 --> 21:47.220 My reading of this just says that some pin types cannot be connected to other pin types, 21:47.940 --> 21:54.020 and it's generally concerned mostly the outputs. You cannot connect it with another output, 21:54.020 --> 21:59.700 otherwise you'll probably have lots of trouble. So you see this connection metrics that 21:59.700 --> 22:07.220 output and outputs are not compatible and poor outputs and outputs and poor outputs either. 22:08.900 --> 22:13.380 The goal here is to warn you if you're doing something that with your outputs. 22:16.980 --> 22:22.580 You have some special pin types that you can read in the metrics. 22:22.580 --> 22:27.940 Namely, I've seen people use and specified, as specified is weird, because it always gives a warning. 22:27.940 --> 22:34.580 Whatever happens, as we have specified pin types, it's like to do or something that will always 22:34.580 --> 22:39.620 warn. So if you have something that you need to be changed later, you can put it on specified, 22:39.620 --> 22:44.820 otherwise it's just popping ERC, so maybe avoid using it too much. 22:46.020 --> 22:51.860 A no-connect pin can never be connected, but if you have a no-connect actual no-connect pin for a 22:51.860 --> 22:58.020 chip, but you want it connected to something like G&D for mechanical reasons or a net of something, 22:58.980 --> 23:05.780 you can also decide that your pin is free, never once. You can connect a free pin to anything 23:05.780 --> 23:11.220 and can be good for a no-connect pin if you want to have a connection in your way for 23:12.260 --> 23:17.700 your diverse reasons. And passive is the dedicated type of pin for 23:17.700 --> 23:24.820 connectors, passive components, resistance, you name it. You can have the dog for the details of the 23:24.900 --> 23:33.380 user types. I run a popularity contest, because I never know what pin type to choose, so I decided 23:34.740 --> 23:41.380 to organize a vote. And the winner is bidirectional. If you have a GPU in a chip, you put the bidirectional 23:42.820 --> 23:49.460 power input if you're supporting passive and passive and then input and output. So 23:49.540 --> 23:56.420 those names are also scary, but we don't use them as much as bidirectional and poor end. 23:58.420 --> 24:05.380 Okay, so the input, the poor end put pins are a bit special, because they require to be driven. 24:05.380 --> 24:12.820 So an input pin, simple input, not poor end put, can be driven by an output for our put passive 24:12.900 --> 24:19.540 free state or bidirectional. So that's quite wide. And you don't see the poor end put 24:19.540 --> 24:26.820 pin not driven by a new put pins a lot, because you actually have a lot of options. 24:28.020 --> 24:33.060 But the poor end put pins, they need to be driven by a poor end, I would put only. So that's why 24:33.060 --> 24:40.020 you get a lot of this input for a pin not driven by any poor end put pin message. It's a putting 24:40.900 --> 24:49.540 really open. And it means that in the same net you have a poor end put, but you don't have anything 24:49.540 --> 24:57.860 that's flagged as a poor output. So in order to solve this issue, well, there's an issue with this, 24:57.860 --> 25:03.140 because well, in a scenario where my pin is a poor output and my other pin is a poor end put, 25:03.700 --> 25:09.540 or C, checker is really happy, so it does not complain. But if I put something between 25:09.540 --> 25:16.820 input output like a passive or something, it will detect that my poor end put is fed by a passive pin, 25:16.820 --> 25:24.260 so it will raise an error telling me that it's not fed by something that gives a power. 25:24.660 --> 25:34.660 Which is why we have a poor output flag. Which is something you can add maybe not run only, 25:34.660 --> 25:41.460 but where the poor comes from, and it will add a just add a poor output pin on your schematic, 25:41.460 --> 25:49.460 so your C checker will detect that, oh, I have poor, and visually you can see that my poor comes from 25:49.460 --> 25:57.860 somewhere. But then I was never really happy about it, but because I could also forget to 25:57.860 --> 26:07.060 power to feed my poor to my passive components. And it's about then that I thought about 26:07.060 --> 26:14.020 fit and discovered interesting thing, that you can create poor input flag in your library, 26:14.020 --> 26:20.260 if you want to, if you fancy it, it's just a component with a poor input pin. And if you do this, 26:21.140 --> 26:26.820 you will force kicker to check that your connected to another poor output pin, because we 26:26.820 --> 26:33.700 will learn the RC checks, that if there is a poor output pin, you need to fed by a poor output. 26:34.580 --> 26:42.820 So this you close the loop, so it's all it's all checked, you can verify that 26:43.540 --> 26:52.340 your poor goes through all your units. So then I will go back to my real life issues, 26:53.380 --> 27:02.900 and if you want to try to guess what's, which RC will pop, so this is my good old typo, 27:03.300 --> 27:10.020 can somebody scream, what will happen as an RC? 27:12.020 --> 27:18.900 Only one. Oh yeah, it's a whole thing, yeah, there is no VDD for 3.3, the rest of the 27:18.900 --> 27:28.900 schematics. I'm connected that label. Yeah, it's an unconnected thing, of course it detects 27:29.380 --> 27:36.420 the unconnection. So, but it's not what's happened, it was too easy. What happened is that 27:36.420 --> 27:42.260 I had a deep coupling capacitor, so it was actually connected to something. So the unconnected label 27:42.260 --> 27:48.260 did not work in my case, it was an alternative, but we haven't connected, we had the unconnected 27:48.260 --> 27:59.460 label too. And now, which RC could, label connected to a single net? 28:02.580 --> 28:13.860 No, it won't raise. Yes, it's a poor one, yeah, because VDD and VDDA and VBAT are flagged as poor inputs, 28:14.580 --> 28:20.500 so KKD will actually detect that it's not connected to bar output, because my capacitor is actually 28:20.500 --> 28:28.340 a passive pin, so it's not driving any power, so this time it will raise a new RC that could 28:28.340 --> 28:39.220 have saved me from making mistakes. And there is a fencing, I do not know it existed, but in this 28:39.220 --> 28:45.860 situation, can you think another RC, so the type was changed, the type of is not capital V versus 28:46.900 --> 28:51.620 smaller, small V. 28:54.100 --> 29:04.020 Yeah, it's a detection from the case sensitivity. If you just have the same name twice, but it's 29:04.100 --> 29:12.180 the case that change, it will suspect that something is actually wrong. So only for the case, 29:12.180 --> 29:18.180 K things, but it will detect the K things, that's not so bad, okay. 29:20.340 --> 29:26.420 So yeah, I present to QFN48, and I present to QFN48, but not the same. 29:27.140 --> 29:38.420 So classic trap, QFNPich can be different, there's a lot of QFNPich is actually, you have to read 29:38.420 --> 29:46.500 the datasheet carefully, but you can also if you fancy it, use a feature, niche feature or 29:46.500 --> 29:55.860 your C of KKD, if you have to help you, it's not solving the problem 100%. Yes, for print filter. 29:57.140 --> 30:01.300 So yeah, you have a feature that's called the print filter, you put it in your 30:01.300 --> 30:08.340 component, it's a simplified regex, don't worry, it's not the full regex thing with all the, 30:08.340 --> 30:15.620 we are the symbol, it's only stars and question marks, you put a footprint filter in your 30:15.620 --> 30:24.500 library, and then it will raise warning if you, the footprint you chose does not match the 30:25.220 --> 30:29.460 filter. By default, it's disabled, you have to enable it, and then you have to make sure that 30:29.460 --> 30:38.660 your prints respect a certain type of rules on how it's defined, you can find a proposition 30:38.660 --> 30:47.860 of rules in the KKD library rules. So yeah, you can see in the examples that here's the 30:47.860 --> 30:57.460 filter is catching a pitch 0.5 and the footprint has a matching pitch 0.5. So it might help you 30:58.340 --> 31:08.900 not mess up the QFN pitch, if you decide to configure it. And last ERC in a real life, 31:09.780 --> 31:18.740 so good old TX and ErX inversion. So you have different variants to make that up. 31:20.660 --> 31:26.500 But there's actually a new ERC, I found that could help, and there's certain conditions. 31:26.500 --> 31:48.180 Well, multiple outputs from the same net. Almost, you can, but it won't pop in this exact 31:48.180 --> 31:55.620 situation. Well, what you can do, well, first of all, you can rename your TX and ErX to something 31:55.700 --> 32:01.220 that describes the absolute direction of where your net is going, very far too, and you can 32:01.220 --> 32:07.780 shoot it very far. I like this option. You can use it. It's really great. But if you want to do it 32:09.460 --> 32:16.500 so-to-re-way, you can also decide that your pin is an output, and if you remember in the 32:16.500 --> 32:25.060 connection matrix, output cannot be connected to outputs. It raises an ERC. So if you decide that 32:25.220 --> 32:31.700 your pin is an output, either by putting in library or using the I create little flag that 32:31.700 --> 32:39.300 has an output pin in my library, you can decide to flag something as an output, and then you won't 32:39.300 --> 32:45.860 be able to connect your TX with another TX, otherwise it will be, oh, you're connecting output together, 32:45.860 --> 32:52.740 it's not really normal. So yeah, and this, for example, it's quite obvious because it's on the same 32:52.820 --> 32:58.820 page, but if you have a design where you have a lot of TX and ErX everywhere on the fitting different 32:58.820 --> 33:06.100 pages, it can be quite useful to have an automated checks for that. But there's an even better 33:06.100 --> 33:13.700 option that it's a new feature. I did not notice it up until recently, but there's a feature in v9, 33:13.700 --> 33:21.140 where you can have a drop down menu and choose the different options for your pins, 33:21.140 --> 33:29.220 because your GPUs, you can choose if your PB6, you want it to be a user TX, and it's not only the 33:29.220 --> 33:34.340 name of the pin, it's also the pin type of the pin, so TX, you can decide it's an output, 33:35.380 --> 33:42.820 PB5 will be a bidirectional, of course, and the user TX will be an output, and if you do this with all 33:42.820 --> 33:50.580 of your pins, they will naturally be output and collide with other outputs, making the check for 33:50.660 --> 34:02.260 a TX and ErX complete. So, as a conclusion, just use the RC, use the maximum RC, everything you 34:02.260 --> 34:12.020 can, clean up the noise, of course. If you can have a sound about your mistakes and also people 34:12.020 --> 34:20.020 mistakes to try. Try to improve your process, and something that's well, we have to remind 34:20.020 --> 34:27.860 that first them, but electrical engineering are not in the habit of using open source lots, 34:27.860 --> 34:33.460 so we have to remind that this time it's not just a vertical option that gives you things 34:33.460 --> 34:43.780 and you say, okay, you can participate in having puts in, okay, so take the opportunity, 34:43.780 --> 34:50.740 if you can, okay, so it's a reference page, but thank you, and if you have any questions. 35:06.020 --> 35:09.220 If you could add one ERC check to keep had what would it be? 35:09.460 --> 35:17.300 I would have lots of your checks, but I don't know if you see people, so I think I would have more 35:17.300 --> 35:32.660 typo checkers, because I have lots of, I do a lot of typos, so I have more things that should 35:32.660 --> 35:36.420 be enabled by default, so some of these checks are turned off by default, maybe we should just 35:36.500 --> 35:42.260 turn them on, would that be better? Well, it's complicated, because they're done up by default for a 35:42.260 --> 35:48.980 good reason. You have one checks that checks a graphical thing, the checks that nets are crossed, 35:51.540 --> 35:57.220 but it's only a visual indication, because it can be legit that you put cross nets in your 35:57.220 --> 36:05.060 scheme, it depends on how you're working and your type of designs, maybe, and a lot of people 36:05.140 --> 36:15.940 they won't do as much a process as we do in digital, but yeah, turn off, if what's one by default, 36:15.940 --> 36:28.820 in turn off, well, the one turned on by default are quiet, I think it's not default options are 36:28.900 --> 36:34.260 quite legit, the football filter is of by default, because you might want to use or 36:34.260 --> 36:43.620 partly libraries, and it will just be impossible to make it right easily, so it's 36:43.620 --> 36:52.980 so-so-ish made that it's of by default, it would just pop too much noise, but yeah, no, I'm quite happy 36:53.060 --> 37:02.260 with the default options. What's your view on this power flag solution? Because at some time, 37:02.260 --> 37:08.180 in my, yeah, I got this, yeah, I've seen multiple times, and each time, I'm like, yeah, am I 37:08.980 --> 37:15.220 really enhancing my schematic by placing these symbols, or I'm just adding more visibility burden, 37:16.180 --> 37:23.620 I'm like, yeah, I usually dismiss this errors. I understand your, I would love to have it 37:23.620 --> 37:27.780 a bit like a net least, or something you can write click and say, okay, this is an output, 37:27.780 --> 37:32.500 or something that is not necessarily shown as a schematic, because I can be hidden as a symbol, 37:32.500 --> 37:36.900 but are you clicked somewhere in order to make them pop, but not having them by default, 37:36.900 --> 37:44.820 because otherwise it's really annoying. Well, you don't need the flag if it's in your symbol, 37:46.020 --> 37:52.020 but it would not be legitimate to have like pouring, putting or and pour out, put in a resistance. 37:52.020 --> 38:00.340 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 38:01.060 --> 38:06.900 in schematic design. It's, it's always difficult because it's kind of a tradeoff between 38:06.900 --> 38:13.780 drawing something that can be read and drawing something that isn't appropriate by software. 38:13.780 --> 38:23.780 So, yeah, those of like ideas, yeah, perfect, but I don't have any idea on how we could do 38:23.780 --> 38:33.060 something much, much better, the point. So, we work on the kick out libraries, and like several 38:33.060 --> 38:37.540 of your slides where there's no, oh wow, we've never seen anything like this before, this is amazing. 38:37.540 --> 38:44.820 So, other than having a power input flag, which we'll definitely be doing, what else would you 38:44.820 --> 38:50.900 like to see in the like changes in the libraries that would make things better? 38:53.780 --> 39:05.780 So, there's only a lot of work on the library. Ideally, I think the MCUs are not split enough. 39:08.180 --> 39:15.860 If I was to use a big, big, big MCU, I think I would do a schematic's different library 39:16.740 --> 39:24.740 symbol in order to have more splits, but it's hard to know without knowing what type of design you 39:24.740 --> 39:30.980 will make because maybe some people will like to have a one-pager and other people will like to 39:30.980 --> 39:41.300 split things on five pages. So, and also I think for now the options, when you can select 39:41.380 --> 39:50.820 the different pins from GPIOs, for those there will be directional. So, if we could have the 39:50.820 --> 39:59.860 right, maybe enforce, I don't know if it's possible or if it would raise too much trouble to have 39:59.860 --> 40:06.260 them as outputs and inputs instead of bidirectional, but it would be maybe a good thing to have. 40:06.740 --> 40:16.500 Thank you for the presentation. When you're working with a lot of people, because the way I see it's 40:16.500 --> 40:23.460 setting up ERC and setting up the symbol, setting up which port does what and so on. So, of course, 40:23.460 --> 40:29.220 they can become a point when it is very specific to the project itself. So, when you're working with 40:29.220 --> 40:35.380 other people and you want people to review your design or if you're sharing the project via GitHub, 40:36.820 --> 40:43.220 how do you approach this thing about telling people, hey, look, run the ERC and if you're 40:43.220 --> 40:49.220 forking this, this is the ERC setup that we have used or if you want to contribute, please do not 40:49.220 --> 40:54.660 ignore this type of ERC warnings. How do you approach that problem where you can very quickly 40:54.660 --> 41:00.020 hyper-specify the ERC and then the people you're working with might not necessarily be looking 41:00.020 --> 41:10.020 to the same errors as you are. So, it's a work. I think most of the set-ups are in the 41:10.020 --> 41:18.180 schematics, in the kayak designs, that not a lot of, yeah, I do have a little bit of tricks with 41:18.900 --> 41:28.420 poor flags and paint type flags, but that's all I ever did, I don't have so many 41:28.420 --> 41:35.300 custom things for now, it's same you are, see about for everyone. And as I say, I like the default 41:35.300 --> 41:43.380 options of kayak, so I'm not changing a lot, upon that. But yeah, you can, yeah, 41:44.340 --> 41:54.020 it can be a niche because a lot of the ERC are ignored because of, they can be, and cannot 41:54.020 --> 42:01.700 be enforced because of typically sub-party libraries and then a lot in an open-out where you 42:01.700 --> 42:09.460 just pull a library that's not from the kayak library and they put less care into making 42:09.460 --> 42:14.180 sure everything works with the kayak system, most of them they export to different cats software. 42:14.180 --> 42:21.220 So, you have to waive a little bit of the ERC, especially the Pintypes ERC because it does not work the 42:21.220 --> 42:29.060 same, but that's the only big difference I see between design. It's most of the time it will be okay, 42:29.060 --> 42:36.660 I guess. And in a way, your ERC setup will be saved with your project, so you know what's happening. 42:37.140 --> 42:44.740 All right, thank you very much. Thanks everyone for joining us today. That's it for the Open 42:44.740 --> 42:50.420 Hardware Cat Cam Devroom. There's still one last set of presentations over in Jansson to wrap up 42:50.420 --> 42:56.980 Fossdom 26. So, thanks everyone, safe travels as you head back home.