WEBVTT 00:00.000 --> 00:12.080 Okay, thank you very much for joining us in the Open Hardware Devroom today. 00:12.080 --> 00:17.680 So our next speaker might need no introduction, but I will give them one anyways. 00:17.680 --> 00:19.040 This is Lucas. 00:19.040 --> 00:28.320 He is the author, lead author of one of the most interesting new projects in the EDA space, 00:28.320 --> 00:31.520 for rising the EDA if you haven't tried it out yet. 00:31.520 --> 00:32.720 You are really missing out. 00:32.720 --> 00:36.080 There's a lot of new paradigms that he has been introducing, 00:36.080 --> 00:40.800 and he is here to talk to us about his plans for the future. 00:40.800 --> 00:44.640 So please give a warm welcome to Lucas. 00:44.640 --> 01:00.320 Okay, so thanks for coming to my talk on Horizon EDA. 01:00.320 --> 01:06.240 As you may or may not know, Horizon EDA isn't the only cat software that I am working on right now. 01:06.240 --> 01:12.080 Since I started working on a 3D cat software named Boom3D bit longer than a year ago, 01:12.160 --> 01:17.280 it was a bit of a type between which software should I talk on, 01:17.280 --> 01:22.320 but since it's been five years since I gave the last public to talk about Horizon EDA, 01:22.320 --> 01:25.360 I thought well, let's talk about Horizon EDA. 01:25.360 --> 01:33.040 So for those of you who don't know about Horizon EDA, it's a full-featureed PCBs, 01:33.040 --> 01:38.480 schematic capture, and they also offer that was basically everything that you need to go from 01:38.480 --> 01:41.280 schematic to finish board. 01:41.360 --> 01:44.960 Since it's been quite a while since I gave the last public to talk, 01:44.960 --> 01:50.240 I'll now go over everything that happened since then, since it's been quite a lot actually. 01:51.520 --> 01:56.960 So let's start back in 2020, so for a project I was working on in back then, 01:56.960 --> 01:58.880 not the one shown here, but something else. 01:58.880 --> 02:09.120 I needed many small boards, and so to make the most economical way is penalization. 02:10.080 --> 02:14.080 So since there was no way to do it in Horizon EDA yet, 02:14.080 --> 02:18.160 I added it in the works the way that you would make in your project, 02:18.160 --> 02:23.280 where you instantiate the board that you want to penalize, can be one project or multiple projects, 02:23.280 --> 02:25.280 and I think the board of the way it works, 02:25.280 --> 02:28.480 and that the board is added by reference, 02:28.480 --> 02:32.880 so that if you have to make some of the last many changes as it always happens, 02:32.880 --> 02:37.680 you just reload them in a panel, and that's it will need to copy paste anything over and over again. 02:38.480 --> 02:41.760 And since it's just a board, you can get very creative, 02:42.320 --> 02:47.840 like here with a combination of these cores and routing to make best use of your panel. 02:50.000 --> 02:52.000 And so for a totally different project, 02:54.720 --> 02:59.520 I had to accurately copy the outline of an existing board. 03:00.240 --> 03:05.120 For other projects that I did the board ten years ago with KaiKat, I did that by 03:06.080 --> 03:12.080 loading the image into an inscape, and then using the XFN port, 03:12.080 --> 03:16.720 that was a bit clumsy, so I thought, well, that's a good excuse to add a picture in port, 03:17.920 --> 03:23.760 and yeah, well, there it is, and it's working for schematic and board, 03:23.760 --> 03:31.120 and you can set things like opacity, scale the image, and render either on top, 03:31.120 --> 03:33.760 or below everything else that's on the board. 03:35.520 --> 03:47.760 So as with every PCBCBD design application, there's a library in my case called pool of parts somewhere, 03:48.480 --> 03:55.120 and with the right idea, it's managed to manage on GitHub in a repo, where people can 03:55.120 --> 03:59.840 approve requests, and so initially, revenue and query requests involved, 04:01.280 --> 04:05.360 pulling that branch locally, reviewing all of the changes locally, 04:06.400 --> 04:12.320 and so on and so forth, and that was really super tedious, and you wanted to do it all on GitHub, 04:13.120 --> 04:18.960 so I wrote a board that parses everything that's in the 04:19.920 --> 04:27.440 pool request, and makes a post to the PR, that includes everything that's in there, 04:28.560 --> 04:35.840 like if all of the checks passed, rendering of symbols, packages, and so on, so the port itself 04:35.840 --> 04:42.080 is part of the codebase of Horizon EDA, it's just that all of it's just a separate binary, 04:42.080 --> 04:46.800 that includes all of the relevant functionality, so one can be sure that what you're seeing here 04:46.880 --> 04:50.400 is exactly what you're going to get later on since it's the same code that renders it. 04:52.960 --> 04:58.880 So when it then comes to actually assembling or debugging boards, it's more of not the 04:58.880 --> 05:03.600 board that you have in front of you on your desk, it's not the same way around, 05:04.160 --> 05:12.400 a subordinate that you've designed, and sometimes then you will tilt your head to see 05:13.360 --> 05:18.960 to make sense of what's where, and that's also something the computer can do, 05:18.960 --> 05:22.800 whereas EDA is a part from looking at a board from the bottom side, 05:23.440 --> 05:29.040 supports rotating the canvas in arbitrary ways, so you can look at your board on your screen 05:29.920 --> 05:31.600 the same way it's on your desk. 05:35.360 --> 05:42.240 So when this day is the for many mechanical parts, like connectors and so on, 05:42.800 --> 05:48.880 you get three models by the vendor, but unfortunately the origin more than not is in the middle of 05:48.880 --> 05:55.440 nowhere, and before I had that feature, I first imported the package in freecat, 05:55.440 --> 06:01.600 then put the origin where I wanted it to be, and then imported it back into Horizon EDA, 06:01.600 --> 06:05.680 since the workflow was really cumbersome, and I had this step model in there anyhow, 06:05.680 --> 06:13.040 I added a functionality that allows you to pick a point from step model and move it to another 06:13.040 --> 06:20.160 point, for example, I could pick the point there on the bottom, and then move it to z equal zero 06:20.160 --> 06:25.360 to place the model exactly on the board, or I can also use paths to align certain features, 06:25.920 --> 06:32.400 and that made important reading models really so much easier, and in a similar way, 06:32.400 --> 06:40.160 related to 3D models, another thing that I did using freecat back then was to make a 3D 06:40.160 --> 06:50.080 2D projection of the model to start my footprint, and I also thought well that would be nice 06:50.080 --> 06:56.000 if I had it in Horizon EDA itself, so I did look at the freecat source code to find the right 06:56.000 --> 07:02.000 opencasted incantation I had to use to get the 2D projection, and well after a bit of hacking, 07:02.080 --> 07:06.320 there is, so when you have your 3D model, you just click on projection, 07:06.320 --> 07:11.520 then you get template that you can use for starting your footprint, 07:14.080 --> 07:21.840 so the pool in Horizon EDA contains the two contains orders, 07:21.840 --> 07:29.600 so that means that if there are resistors of certain values, you'll have one part where 07:29.600 --> 07:36.480 every value, and that this can get by long, with some parts not really being really available, 07:37.200 --> 07:45.040 so Horizon EDA can tie into the DJK API, which has quite a generous limit of 1000 previous 07:45.040 --> 07:52.320 per day, and can then write in a park browser to display how much of that item is in stock at the 07:52.320 --> 07:59.440 GG, so a big feature that I've been wanting to implement basically since day zero, 08:00.320 --> 08:08.400 I had some initial plans for implementing, but after thinking about them at more turns out that 08:08.400 --> 08:14.320 they were really user friendly with having one instance of the schematic at the top hierarchical 08:14.480 --> 08:25.280 block, so now the editor can support multiple instances in one, multiple blocks in one editor, 08:25.280 --> 08:30.240 and you can easily switch between them, then you can also easily switch between the instances 08:31.120 --> 08:36.320 where you can then make changes to parent designator and you do not populate state, 08:36.320 --> 08:43.360 and you can also then edit the symbol for the block and place the block pins there and everything 08:43.440 --> 08:51.040 that you need to make hierarchical schematics, and it's also then in all the possible in the board 08:51.040 --> 09:01.280 to copy and paste, placement and routing between hierarchical blocks, so every and every now and then 09:01.280 --> 09:08.480 people were asking me about only B++ export, not so much for a manufacturing, but they had some 09:08.560 --> 09:14.400 significant employee integrity as software, that only input input or the B++ in one of some other 09:14.400 --> 09:18.240 release range formats, so I thought well would be interested what's the interesting challenge, 09:18.960 --> 09:23.360 and turns out that nowadays you can just download these specifications from the ODB++ 09:23.360 --> 09:28.160 website and there's also a free viewer and some sample files to add everything at hand to 09:28.160 --> 09:34.880 implement ODB++ export, a couple of weeks later there is, so horizon EDA and also ports ODB++ 09:35.760 --> 09:41.920 and as far as anywhere some people apparently have also used it to get ports made, and after I 09:41.920 --> 09:48.320 was done therefore there's a form on the ODB++ website where you can become a partner 09:48.320 --> 09:53.200 that lists you on the website, while in the form couple of weeks later with some back and forth, 09:53.200 --> 10:03.120 horizon EDA is now in there, so somewhat advanced feature that some people have been asking 10:03.120 --> 10:07.680 no idea if someone ever actually were the bot mate with that, were blind to barred by us, 10:07.680 --> 10:15.440 initially horizon EDA just supported a through BI, since what ever but what just what most people 10:15.440 --> 10:22.240 can afford, but since the feature that probably someone might need in the future, and horizon EDA 10:22.240 --> 10:28.720 also supports blinded barred by us in a way that you set up multiple via definitions, so you can 10:29.600 --> 10:35.440 put in the information you've got from the bot hours in terms of stack up in there, and then 10:35.440 --> 10:40.480 when routing tracks and placing via as you can pick from one of the defined via us in there, 10:43.680 --> 10:49.680 and so one last feature related to more advanced bot technologies are user layers, 10:49.680 --> 10:56.800 some more advanced technologies for boards, they need extra layers for example, like for 10:57.760 --> 11:03.600 widget flexboards or just random annotations, so you now can insert arbitrary layers and 11:03.600 --> 11:11.280 arbitrary places in the stack up, and they can also be assigned the type that's mostly used for 11:11.280 --> 11:20.960 Ruby++ export right now, so as with pretty much any interactive software, the user spends 11:21.040 --> 11:27.360 much time selecting stuff, and one thing that I found quite annoying was I was moving some items, 11:28.000 --> 11:31.600 then move something else, and I think it will, oh well, now I need to move the thing that I 11:31.600 --> 11:37.120 move the minute ago again, so horizon EDA now maintains under redo buffer for the selection, 11:37.120 --> 11:43.600 that's independent from the actual under redo buffer, so when you select something, and one 11:44.560 --> 11:50.480 again you can just use the under selection shortcut, and then get back to what you had selected 11:50.480 --> 11:56.720 a couple of minutes ago, seems like a really trivial thing to implement, but I haven't seen it 11:56.720 --> 12:03.040 anywhere else, so that's one of the nice things about writing your own software, this is pretty 12:03.040 --> 12:12.480 easy to go from, well, it would be nice, it can do that too, well, here it is, so now we are in 2024, 12:12.560 --> 12:21.840 which is almost the present, so if you paid some attention to the date on this slide, 12:22.400 --> 12:30.800 you might have noticed that there was a lot of activity around 2020, and not so much in 2022, 2023, 12:31.360 --> 12:42.240 and so one reason for that is that in late, the thing in late 2023, I started working on 12:42.240 --> 12:50.240 the entry-deer, which is a parameter, a 3D cut software, so since horizon EDA is mostly 12:50.240 --> 12:55.840 one person show with some drive-by contribution from users, there's only so much time I have, 12:55.840 --> 13:02.480 so horizon EDA, whatever that's time, and it's also pretty familiar, it's pretty much doing what I want, 13:03.520 --> 13:08.240 and so as usual I did some projects with it, then that's the initial reason why I 13:08.240 --> 13:12.880 make horizon EDA to make it easier for my own projects, and some of these are shown here, 13:12.880 --> 13:20.720 like the USB-KVN project that you may or may not have thought about, and another project that I did 13:20.720 --> 13:27.920 was the replacement, the replacement PCP uniform of the SD card reader to replace one outflash 13:27.920 --> 13:36.320 in switches, so apart from the horizon EDA project itself, there's also the pull repo with all 13:36.320 --> 13:44.400 of the parts in there, and that's one of the things where the project isn't in technical shape, 13:44.560 --> 13:50.080 since while reviewing this pull repo, it's quite some work, and it's really work, and I 13:50.080 --> 13:55.680 don't find really much time motivation to do it, so yeah, there's quite a lot of pull requests 13:55.680 --> 14:02.480 that have piled up, the pot makes it some more easy to review, but there's something that I don't 14:02.480 --> 14:08.960 really like doing, so people are mostly under own when it comes to making parts, or going through 14:08.960 --> 14:17.360 pull repo and see if there's something that they like, but so the central pull is everything 14:17.360 --> 14:22.720 people can also make their own tools, and mix and match them in a project as they like, 14:26.000 --> 14:31.200 so something that people have been asking me every now and then, there's how many people are 14:31.200 --> 14:38.000 actually using horizon EDA, so to get, since there is, I don't have any, and you don't know 14:38.000 --> 14:45.280 stats for the releases on, on GitHub for, but these are only for Windows, but there are some stats 14:45.280 --> 14:50.480 on that hub for intros or while time, but these numbers, I don't know, they seem really 14:50.480 --> 14:57.680 open-sighted to me, maybe it's just some scripts, or whatever downloading them, so my best guess, 14:57.680 --> 15:03.920 it's like a single, like a double, a small bubble, a little number of users, a thing is definitely 15:03.920 --> 15:12.640 more than 10, but of course, much less than 100, and I think that's also like, for one person 15:12.640 --> 15:16.160 part, like that's a good number of users, since if you have more users, you will get overwhelmed 15:16.160 --> 15:22.480 with feature requests and really strange parts, so I'm going to put it the way it is right now, 15:23.120 --> 15:30.320 and now the probably the part that you call all can hear from, namely what's going on in the future, 15:31.200 --> 15:37.680 so it's been a couple of years now, since GTK 4K mod, and horizon EDA is on GTK 3, 15:37.680 --> 15:44.080 since that's what the latest thing was when I started it back in 2016, so people that I have been asking 15:44.080 --> 15:53.040 well, will you ever purchase GTK 4? So the answer is probably not in the new future, since I have been 15:53.040 --> 15:59.760 using GTK 4 for a new 3D, so I've got some experience there, and well, it's a lot of work, since 15:59.760 --> 16:06.560 there are some deprecated APIs and some things that are just different, so it'll be probably 16:06.560 --> 16:14.400 be half a year of work, and afterwards it'll still look the same, and well, it's not really 16:14.400 --> 16:22.320 benefit to use other that GTK 4 has a longer time to up to less than GTK 3, so one of the things that's 16:22.320 --> 16:31.520 been bothering you the most is that if you make some moderately large parts, the rendering can 16:31.520 --> 16:39.520 get a bit laggy, and that's mostly because for every render when you move something, it iterates 16:39.520 --> 16:45.200 over the whole board and generates the vertices from that, and there's only I've been tweaking 16:45.200 --> 16:51.200 this every now and then to make it a bit faster here and there, but the real thing to make it 16:51.200 --> 16:58.880 really fast is to make it incremental, so that it just withdraws what's user is moving and 16:58.880 --> 17:05.360 has to rest, so basically it's somewhat similar, like how it's already done, with integration 17:05.360 --> 17:11.600 of the calculator, since it also operates that way that it just hides the parts that will 17:11.600 --> 17:20.400 be changed and then only clears and redraws what's being changed, so a feature that I'm probably 17:21.360 --> 17:29.600 need for a future project is a hierarchical bus ports, so right now bus, it's also right now 17:30.560 --> 17:36.800 ports for hierarchical committees can only be seen on that, but when you have a large amount of signals, 17:36.800 --> 17:43.040 like a bus, for example, and that's a little poorly, even that, then you don't want to have 17:43.680 --> 17:50.240 going to connect a signal there every time, so probably sometime this year there'll be 17:50.240 --> 17:57.680 hierarchical bus ports, and apart from that, there are some pending equality of life improvements, 17:58.400 --> 18:04.000 for example, when you change the part in a pool somewhere, then you first have to go to the 18:04.000 --> 18:10.240 pool to the cash pool in the project, update the part there, then go into the schematic and reload 18:10.320 --> 18:18.000 the pool there, which is just two steps, and with a bit of work, it'll be possible to combine 18:18.000 --> 18:28.400 all of these into a single step. Yes, and the thing that will be probably it for the new future, 18:28.400 --> 18:32.880 there are some things that I've been also considering, like adding variants, 18:33.840 --> 18:42.240 while these are mostly features to have them, but not really features that I need or I've 18:42.240 --> 18:48.400 ever about anyone needing, but some features like for example, variants would be just very fun to 18:48.400 --> 18:57.360 implement, and last but not least, it's all the time for a new release sometime, since the last 18:57.440 --> 19:05.120 release has been about a thing a bit less than a year ago, and there have been quite a lot of 19:05.120 --> 19:13.440 bug fixes, paddling on since then, and yeah, they used to be a lot more releases in the past years, 19:13.440 --> 19:19.040 but I think now I think these cadence of probably once a year or so is something that's manageable, 19:20.880 --> 19:25.680 and that wraps up this talk, and that's it, if you want no more world projects I said 19:25.760 --> 19:30.000 to go to the website, there are all of the content information like matrix channel, 19:31.120 --> 19:33.280 and the documentation and all of that. 19:41.920 --> 19:42.720 Are there any questions? 19:42.720 --> 20:01.280 So when you are looking at your governance of the project, and you look at your open issues, 20:01.280 --> 20:06.640 and you say that is way more issues than I want to deal with, have you ever considered 20:06.640 --> 20:13.840 taking on an additional maintainer to deal with some of that housekeeping that maybe your 20:13.840 --> 20:19.200 users are looking for? So the question was, if I've been looking for some extra maintainers, 20:19.760 --> 20:26.720 so I have been not actively asking people, but for the for the for the pre-record, there are 20:26.720 --> 20:31.600 things now two more users that have permissions to merge, they have been merging stuff 20:31.680 --> 20:37.840 sometimes, and for the main repo, it's been mostly clear of like contributions by users that 20:39.680 --> 20:44.720 wanted to scratch their own niche, and I think that's fine with me. 20:48.240 --> 20:55.040 Yeah, so you showed earlier the gift up screenshot with $129 open request, 20:55.040 --> 21:02.880 and we know that feeling. Yeah, so one thing we ended up doing for kick-out was actually asking 21:02.880 --> 21:08.000 people who contributed a lot of parts. Hey, you're putting so much time into this, would you like 21:08.000 --> 21:10.640 to review some? Have you had any success doing that? 21:10.640 --> 21:18.240 Yeah, I think that's two people that I mentioned in the last question was, if any success convincing 21:18.240 --> 21:22.560 people that contributed parts to review parts, well, there's been some success in this 21:22.640 --> 21:27.040 obviously being not that beneficial contributing, I have not had two two people that 21:27.040 --> 21:31.040 sometimes had to have with the review, but it's also been a while since they last 21:31.040 --> 21:38.480 back with something, so I think it's been okay. 21:39.440 --> 21:55.200 So you mentioned something about rendering being slow, can you elaborate? Is it about 21:55.200 --> 21:59.440 let's say, desolating the model, so is it about something else? 22:00.640 --> 22:07.120 Can you just repeat the questions? So you mentioned that rendering is slow, is that specifically 22:07.200 --> 22:14.480 related to, let's say, desolating the models that you have or is it related to something else? 22:14.480 --> 22:17.840 Okay, so the question was whether the rendering is slow to put desolation or something else, 22:18.480 --> 22:24.080 so if you would call desolation converting the actual thought geometry to vertices, 22:24.080 --> 22:31.600 well, that's what the part of the rendering is, and that's really the part that's being 22:31.680 --> 22:35.520 slow, and it's just it has to iterate over the every part, over every part, over everything, 22:36.400 --> 22:41.040 and that's, and yeah, I've been trying to make it faster, but there's only so much to 22:41.040 --> 22:47.920 can do, so much speed, gain you can get by just tweaking the existing code, other than, yeah, 22:49.760 --> 22:52.000 re-accordacking in a way that it's incremental. 22:52.720 --> 23:00.080 Let's say your models that you're rendering are burebs or are there already, that's a polygon base? 23:00.080 --> 23:06.880 Or so the question was, if the multiplying rendering are burebs, so for the, so there's a burebs, 23:06.880 --> 23:12.720 for the 3D view, but these are converted to two triangles, one's on import, and in the 23:12.720 --> 23:19.520 port itself, it's basically just lines, arcs and polygons, and the renderer uses 23:19.520 --> 23:25.680 makes use of open, so the renderer itself uses OpenGL with geometry shaders, and there's 23:25.680 --> 23:31.120 no trimotives like a line with a rounded corners and a border or arcs, 23:32.320 --> 23:36.720 how all of the low-letter rendering is done on a GPU in OpenGL shaders. 23:39.920 --> 23:47.280 So I would have the question, what was your initial mindset or the need that you started before 23:48.240 --> 23:55.120 so the question was, why thought that with Ryzen DA, so back in 2016, when I thought of the project, 23:56.240 --> 24:04.880 I wasn't quite happy with the way the libraries in T-Catwork, since I thought, well, I want to have 24:08.080 --> 24:13.920 net-less representation, that is, which pins this part has separate from the single representation, 24:13.920 --> 24:19.840 and also have the separate from the pin to pad mapping, and since that's well a 24:19.840 --> 24:24.960 pretty central aspect of how the idea is of the operators, and so you can't trust really change 24:24.960 --> 24:30.080 the foundations of a software, that easily, so I thought, well, let's try writing my own, 24:30.080 --> 24:37.360 and I had some, I think, two fall starts, one with Python and C, one with just C, and then I think 24:37.360 --> 24:41.600 of the couple of months, I settled with C++, and from the end. 24:49.280 --> 24:58.320 So you have a very complex application that you have developed, obviously, one person can't 24:59.040 --> 25:04.720 build and develop and maintain all of the aspects of the system that are required to 25:05.680 --> 25:14.880 make something as complicated as useful as the EDA, are there particular packages that Ryzen 25:14.880 --> 25:27.360 depends on that you are, especially, indebted to are things that you found particularly useful 25:27.360 --> 25:28.720 as you're developing this? 25:29.680 --> 25:35.680 Those are the questions, whether they are, so to summarize, if there are particular dependencies 25:35.680 --> 25:47.680 that we are super useful, so I think the most important thing, that's the most important thing, 25:47.680 --> 25:53.440 we probably be the cacadvator that I'm using, since the interactive water that's part of KaiCat 25:54.400 --> 25:59.280 was developed in a way that it's not really title-cacad in a very hard way, 25:59.920 --> 26:06.960 so since writing my own water wouldn't have been too much, I early on in the project 26:06.960 --> 26:09.600 started using the KaiCatvator and that's working really well. 26:10.880 --> 26:18.000 Another dependency that's super useful is open cascade for dealing with a step model import 26:18.080 --> 26:26.240 and regulation of them, so yeah, the so far I've been only really content with open cascade 26:26.240 --> 26:30.320 when it comes to a step import and also for a step export, so this is a really 26:31.120 --> 26:36.960 thing to give dependencies apart from other dependencies like PDF libraries and stuff like that. 26:41.040 --> 26:42.000 Okay, thank you Lucas! 26:48.000 --> 26:50.000 Thanks for watching!