 So, hello everyone and welcome to my talk on horizon. The free EDA package I started working on for about like a bit over a year now. So, to get started, let me explain to you why someone would write a brand new EDA package in 2016, even though like there are still many around. So, these are my main points of motivation. First of all, I thought that the management of symbols and packages and stuff wasn't quite solved the optimum way I liked it. Also, supporting actual parts is still something I didn't see solved to my liking. As you may know, pretty much every EDA software consists of many editors like boards, schematic, package symbol and stuff. And I wanted to unify all these so that these share code and share the same use experience. And another important aspect was to have a schematic editor that actually understands what you're doing and just isn't a program that lets you draw lines and tables and then figures out a net list. And one something that really can help you with drawing schematics. And last but not least, I also placed emphasis on rule-driven design for meeting design rules and stuff. And some implementation details include like making use of explicit references. So, not doing things like one pin is connected to a net line. If they happen to be on the same location on the sheet or that like nets are connected if they happen to have the same name. And since programming also has to be fun, I found using modern OpenGL to be quite enjoyable. And doing it from scratch, a program also gives the possibility to try new things. So, let me give you an overview of the implementation details. Horizon is written in C++ 14. This caused some issues in the past since compilers still are getting smarter even though I thought that these would be pretty mature already. It's about 50,000 lines of code without the included external libraries and dependencies. It's using a GTK3 for use interface which gives us things such as high DPI scaling for free. And right now, it builds and runs on any reasonably modern Linux distribution and Windows and it should run and compile on free BSTs as well. Unfortunately, Mac OS is out at the moment since the Quartz back end of the GTK3 on Mac OS doesn't support OpenGL. And I'm using a JSON for a file format everywhere since that makes interfacing with external scripts much easier. And everything, really everything from the pin to an ad, symbols and stuff it's all referenced by UUIDs. Since these are easy to create and they are practically unique by guarantee. So let me explain to you what I meant with the first point with management of symbols and stuff. The classic approach is to have libraries. You have a library, in a library you have symbols or packages that have similarities like being a resistor or being a logic gate. I didn't quite like that approach since it's like having a file system with only one level of hierarchy, which doesn't make organizing things very easy. And these aren't also data based where you can just use SQL or something else to query. Instead, the pool, in the pool, it's like having just one library. In the pool, each item like so, each symbol, each package and stuff is all placed in its individual JSON file, which makes merging stuff easier. And since like having a bunch of files scattered around in that directory, isn't that easy for searching? All of the metadata of these files that's scraped into a SQL database, which makes searching a breeze. And to remove the cluttering stuff, the pool is only supposed to contain parts that you can actually buy. So there won't be like a generic 10K resistor or 6 or 3 resistor there instead. You should only like go to Digikey and use the exact manufacturer. Manufacturer's part number since that's the only way you can generate a reasonable bomb. Yeah, so that's how the pool looks. Some of you may be familiar with things like symbols and packages, but what are these and why do we need these? First of all, let's start with the most tangible thing, the part. As I explained just before, a part is a real thing. So a thing with a manufacturer and part number, where you can just go to a Digikey type in the part number and you will get exactly the same part you want. So that also includes like slight variations such as temperature grade and stuff, but that's the way it has to be done to maintain consistency. Next on, there's the package. Packages are rather straightforward as well. It's just like in pretty much every other EDA package. You've got your lines for filtering and stuff. You've got pads. You already have the additional layers such as courtyard or assembly outlines and assembly reference designators. So but now things get a bit more special, namely how the pads are defined. Like many other EDA packages just offer like a selection of basic pad shapes. But what turns out that manufacturers, especially connector manufacturers, really like to create custom pad shape for whatever reason and horizon supports the out of the box. So a pad isn't something single like a rectangle instead of a pad stack. Something that you draw like anything else. So you basically draw your copper layers, place your drills and all that. So arbitrary pad shapes are basically built in. Now, that raises the problem how to handle simple pad shapes like rectangles without redrawing the rectangle for every single size. To solve this, pad stacks can be parametrized. And to do so, a pad stack can be accompanied by a program that's custom stack based language to keep things easy. It's liberately non-touring complete so that it always terminates in infinite time. And it's basically just a way of writing mathematical expressions. So that the program can take external data such as like pad size or pad size or other stuff. And modify the pad stack itself to suit these requirements. Now let's know, now you may be wondering where the pins are defined. Like you could go the traditional way and just define them in the symbol. But I didn't quite like that approach since I wanted to really separate schematic from netless representation. So that was all for obvious reasons. I also didn't want to specify them in the part. Since you have many basically identical parts such as like resistors. Netlist-wise, they are all the same. But yeah, so to do so, there are the types entity and unit. The unit is a thing that actually defines the pins. So you can think of the unit as things such as a single end gate, a single end gate, as a single op-amp. Or in case of parts that only have one gate. For example, a microcontroller is a simple one. The entity just references the single unit. And the entity is a thing that groups the units and makes the logical device out of them. This is the advantage that for the net list only cares about the entities. So when we want to change a resistor from a 10K one to a 1K one, the net list doesn't care since the entity stays the same. There's just a note in the net list that tells this instance of this entity, this component, it has this part. I guess some of this make it clear in the demo. So and last but not least, there's the symbols. Symbols are pretty easy. They just take the pins as they are defined in the unit. And you're supposed to draw all the usual symbol stuff like the pins and the text for reference signatures, values, and all the other decorative stuff. These small arrows you see there, they are just for showing what's input and what's output. As I already told, I wanted a schematic editor that actually knows about nets. So we could always generate a net list on the fly. But that seemed kind of silly to me. So that's how it's implemented. The net list is edited in parallel with the schematic. And the actual connections are defined from the net list and net names. So and the schematic reads the net names from the net lists for net lists and places the appropriate labels and stuff if they are there. As I line out in my motivation, proper rules and checks are important as well. Since in the end, you want to manufacture your design. And you need to meet certain rules, like the rules of the PCB house, and both your rules to ensure that the design actually works. Right now, there are things like rules can actually set a track width. I'll show that in a demo how that works. Rules can match certain things. So a rule only gets applied if these things match. And rules can also be checked for, like clearances and hold size and track width and stuff. And these rules provide a framework for basically all things that can be checked. So we have the framework that makes it easy to add new checks for ERC, DRC and style checks for packages and stuff. Even though the project is rather young, I started working on it late 2016. It's been public since about a year now. And it's been actually ready for public consumption for about three months. Like these are all the things that are working. Some of the things, like the interactive router, are leveraged from KiCAD, especially the KiCAD router. It's developed rather separately of KiCAD since it has its own data model. It was surprisingly easy to integrate that. So right now, Horizon has the same awesome router that KiCAD has. And also, the handling of step models for important export was also adapted from KiCAD, as well as the calculation of the red-nosed air wires. So that's actually rather difficult. And they also support the usual stuff under real copy paste, even though some of them are bit as still an experimental. Yeah, some things are still missing. Since my plan is to have one global pool, there needs to be a convention in place that everyone adheres to. There's some work in progress that someone on the internet started and had some really, really good ideas. So I think that could go somewhere and we could also adapt things from the KiCAD Library Convention since they did a really great job there as well. So last but not least, thanks to everyone that helped me in the project, especially friends and testers, many people on the internet such as on the EV blog and microcontroller.net forum and on GitHub that file issues and basically helped me. And also, I'd like to thank the KiCAD people. Since without KiCAD, Horizon wouldn't be what it is today. Since without a router, things would be much less nice. Now let's head on to the demo. So there are basically two main entry points to use the user interface. For one, the project manager and the pool manager. I'll start with the project manager. So let's just open an example project and open the schematic. So you've got your usual schematic. So you can drag on that just by starting, dragging and starting from an existing junction. And now let's actually put some, so I thought there's a USB connector in there right now. Now just let me delete that one so I can show you how adding new things work. I select place part, then the pool part browser pops up. It's normally a bit better if you've got a screen with a higher resolution. So let's place that USB connector. There's a preview of the symbol and to the right, there's a preview of the package how it looks like. Just let me place that one like this, rotate it. Now I press O to add like a round symbol that attaches like that. And just let me connect this just by clicking and dragging from there. And also let me add some labels to connect these. So let's just name this net like USB, the minals, and USB D plus. And now instead, so if I would like to do it like as unusual and so I'll just rename this, then this will show an error since like now it created a second net with the same name and that will cause a warning. And what I have to do instead is to use the tool to move this net segment to other net. So like take these things that are connected to this net segment at the moment and connect them to a new net that makes things much more explicit. So I just connect this one to USB D plus and this one to like USB like USB D minus. And just because we can, let's make them or because it's useful, let's make them a differential pair that's as easy as that. So let's save that, go to the board editor and go back to the schematic editor and click place part to board. And this will pull up the board editor with the part editor for placing it. Let's place it just here like so. And use the interactive router in the differential pair mode to just route this differential pair track to the USB pins of the micro controller just easy as that. And also like it supports all the things that you know from the packet router like not making collisions and stuff. Just let's hope that this fits on the screen. That's how like the clearance rules work. You can add rules that like match certain nets. You can either match like net like net class or the net itself or the net name using a regular expression. And for each match you can you find you have your full clearance matrix. So it's sort of like the minimum distance between these types of copper. And when looking for the right one it just starts at the top and looks for the first one that matches. Like I guess users of Altium may find this a bit familiar. Yeah, and there are also other rules such as like clearance from copper to non-copper things for example like board edges or holes. And also other rules for copper planes and rules for track width. So if a track has a width set to be loaded from the rules. I can just alter the track width in there, hit apply, and then it gets applied to all the tracks so that I don't have to change everything. And everything stays nice and consistent. Yeah, and I also got a 3D preview. Right now it takes a bit to load the models. Since these are step models and triangulating them takes a bit of time. Now they are there and I have also some visual aspects like I can change the background color and some feature that actually might be useful. I can when I like let me turn off some of these and to better see how the layers are stacked that I can like explode these. So I can actually look into the PCB and right now it's a bit silly. But I guess it's useful when you got like PCB with many more layers. Yeah, I also got some like goodies for example. Instead of using the usual things for like box selection, I also have selection modes such as lasso. So I can just draw a lasso and everything that's within it will be selected, yeah. And as the KiteCat people do, I also got like a selection filter. So if I know, for example, I only want to select tracks. Just select tracks and it'll only select tracks and not like packages and stuff. Okay, then it's time's up and questions please. So just go to the first page and find the link to the GitHub repository and just like file issues, open pull requests and stuff. You're welcome. Do you have some kind of IRC or something like that? No, I don't have like a dedicated IRC channel. But if there's a need for one, I guess we can just wear a channel or 3.0 or FTC also. Yeah, let's just let me delete the USB connector I added. Let me delete this in here. I'll press save to safety netlist and then I'll press reload netlist and then it's gone. Yeah, yeah, yeah, okay, so the question was why not contribute to KiteCat? As I explained earlier, I really wanted to implement the parts management in a proper way since like how parts and symbols and stuff are managed is like the core of every EDA package. Like changing that would need changing everything. So it's also we would have cost a lot of friction since like as I said, the way how the symbols and packages are handled is really the core. So that's why it's decided to start over. Well, I mean, historically, I hope the other ones don't, like by the time Git came out, there was Mercury that was just on the console. You know, Mercury was great, but it just never caught on because it got the whole thing. And again, it's wonderful stuff, I don't want to criticize the words. I had a similar question. I mean, in KiteCat, the number one complaint of users is library management. Yeah. So it looks like if somebody proposed something, yeah, there would be fertile ground. Yeah, but yeah. Yeah. Did you try discussing with the KiteCat? Actually, I didn't. Yeah. Which I'll sort of make the same thing that I made in the previous talk. Yeah. But I'll make it in a different way. It seems everybody is inventing a new file file. Yeah. You mentioned Jason. Yeah. And I look at that, and I look at Jason, and I accept math style, and see style, list book style, you know, you name all those things. Yeah. But what really matters when you look at it as a file format is how is it organized. And this is something that always comes secondary. And one thing that I've noticed about the formats that are used in layout, and stuff like that is that they're basically drawing format. Yeah. It's a drawing first, and your circuit that it represents is secondary. And what I kind of like to see is that flipped around, where you have this, where the circuit that it represents is primary, and things like the placement and stuff like that is markup. So how to repeat this? The previous one about the layout, the layout features, because that's the way they look at it. But the bit about, I see all these neat tools that they don't work together. Time for one more question. OK, three very quick questions. You, you and I. Yes, please, make a T-shirt. Yeah. Well, how is the method that your program generates compatible with the method that's called our program? No. So the question is whether or not the methods are compatible. No, they aren't. They are just JSON. Since my thought of storing things was just like serializing the internal objects. And compatibility, in my opinion, can be cared for by exporters. OK, one from Plaspar, and then on the character virtual, and let me use it. OK, so the question was whether it was hard to integrate interactive router. Yeah, there were some impedance mismatches, such as the keycage router, like thinking of things being connected if they are on the same position, like in Horizon, if they connect to the same junction. So I had to do some like matching things in there. But it also required some changes to the canvas to interactively hide things and stuff. But overall, it was doable. Yeah, I did so once just by doing a get pull on the keycage reaper and using melt to not change this over, since I didn't modify the actual router. Since all the interface between the router and host application is in its own class. OK, last question? Both. OK. I'm asking because my idea is, you know, we all hardware engineers do PCB design pretty much every day, and we learn to live with different systems. Priority software, I'm not going to mention here. It's not so bad. OK, look at it again.