 Hey, so today I'm going to give another talk on my EDA package of horizon EDA. So just for reference, who hasn't heard of that project yet? Okay, so quite a few. So horizon EDA is a full-featured EDA package, so it does everything from library management, schematic capture, board layout, 3D preview and export, and up-to-gover export. So you can use it to store just the basic EDA package. So you might be wondering why did that guy decide to write his own EDA package instead of contribute to something that's already existing. So some people say that a board can only be as good as the library of the parts. And so to me, that's all that's true for EDA packages. So an EDA package can only be as good as the library data structures. And I saw a significant deficiencies in existing EDA packages in that regard. So that was one of my main reasons for starting a new one. Since, for example, in Kycat, the part definition is basically the symbol. The symbol, the pins itself, and also contains the pad names. And for me, that shouldn't be all in one thing. And I also wanted to have a unified editor, so basically the same editor with all the same shortcuts and features for everything from symbol to board. And I also wanted to have a schematic editor that actually knows about nets and just doesn't let you place labels all over the place. And to actually design board, you need to properly specify your design rules. And that was also a key point for developing Horizon. And some implementation detail was that I didn't quite like about existing EDA packages that they just happened to connect things if they had the same name or just happened to end on the same location. And in Horizon, everything that is connected is actually linked in the data structure by ID. And I also wanted to play with new OpenGL3 features and I just wanted to have something I could play with and easily try out new things. So some details on implementation, it's written in C++14. It's around 70,000 lines of code right now. Just for reference, the included Kycat router that doesn't count to this number is about 20 lines of code. So I think it's quite small for what it does. It uses GTK3 for a UI toolkit and builds and runs on any recently, any more or less up-to-date new system and windows. And people also reported that it builds and runs on BSDs. It uses JSON as a file format and everything's linked by UUIDs. So let's get back to the first point. So what's wrong with libraries? So they're more or less like a file system that only has one level of hierarchy. So if you've got a library and then inside library you don't have that much structure. And it's not a database that you can run SQL queries on. In Horizon, each item in the pool, so each package, each symbol and so on, is in an individual JSON file. And the data of these files gets loaded into a SQL like database. And that database can then be easily queried for various properties. And the idea of the pool is that it only contains, like actual parts, you can order on DigiKey. So you won't find, for example, a generic NE555 timer in there. But you will find any 555 timer manufactured by ST in an SUA package with the full part number in there. So how does the pool look like? So on the top, you've got the part. And so what are the rest of the things with names like entity and unit? So the part is like an actual part. But so a part is something that you can go to and order any way you like, and you will get exactly the same one each time. But the part doesn't specify any of the things like the actual package. So it just referenced the package but doesn't specify the actual footprint itself, same with the pins. So the package is just your regular package with pins, pads and other layers such as silkscreen and courtyard layers. And in Horizon, each pad is drawn by itself. So there aren't technically any pads built into the code. They are all part of the pool. So real pad shapes are there by default and don't require any ugly hacks. And these pad stacks can then get modified on the fly, for example, by rules using a stack machine. So that one feature that the guy mentioned in the packet presentation, that's possible in Horizon since pad stacks get parameters from the package, package get parameters from the board. And for example, the things like the solder mask expansion or paste mask shrink come from the design rules and other things are also doable with that method. So the logical definition of a part is grouped into unit and entities. So a unit is basically the prototype for a gate. So for example, in a quad-end gate, you'll have four gates that each reference the end gate unit. And one unit is references to the power unit. And that's just a basically list of pins with their direction. And these pins also have alternate names since these days you often have microcontrollers or FPGAs where a single pin has like 20 functions. Some people then put, then just put like only PBB zero in there. And you don't know if that's I square C or SPI. And in Horizon, each pin has one primary name that would be PBB zero in that case. And you can have as many secondary names as you like. So in schematic, so you'll be able to pick in schematic which a name will then appear. And of course, we have symbols. Symbols don't define the pins, they just read the pins from the unit and map them onto something that's actually visible. And because of that, you can also have one symbol for a unit. So you could have for example a European or US symbols or symbols of different widths to accommodate the number of pin names you've selected. So that was basically more or less the same that was there last year, now onto what has changed last year. So the biggest thing in my opinion was that Horizon has seen its first real-world usage, in that case it's been my master thesis. So my master thesis was developing a board for an expand transmitter. So basically the full signal flow from data generation in FPGA to a D2A converter to PLL for local oscillator generation and up finally the up converter. And my supervisors at the University of Stuttgart were kind enough to let me use my own EDA package and I think that really helped since it definitely raised my motivation for doing the actual board and also helped Horizon to be used for real board. So that really got some features ironed out. So that's the board in 3D, just to give you a brief overview with the FPGA D2A converter and local oscillator generation in PLL and the mixer for final up conversion. And it's for layers and has about 200 components and also has some more advanced features such as differential pairs. So one feature that really helped to get this board on properly was the length tuning feature. So this D2A converter requires that the clock line is longer than any of the other lines. So the data gets sampled properly and with Horizon you can just measure the length of all tracks interactively. So you'll get this nice window that shows you the length of all the tracks you've selected before and that window updates in real time. So you can drag these things down there and that window on the left will update in real time. So there's also the length tuning feature from the Kaikai Droughter. It works but personally I don't like it that much since I prefer to place them in the end of by myself. So since you will need to order the parts for your board, Horizon also has a Bomex port. Since we already have the apartment partners from the pool, Bomex port is a really natural fit. And right now the Bomex port just exports plain CSV. But that's what everyone uses and you don't have to use any kind of external scripts to reformat your bill of materials list. Just recently Horizon gained parametric part search. So since the pool will in the future contain thousands of parts and you will need to be able to search for these easily. Each part can have parametric data attached. For example, for registers you will have value or tolerance and these can be easily searched for in that interface that should look pretty familiar to everyone from various distributors. So since we have all the data like description of parts or links to data sheets, we want to access that quite easily. That's why Horizon has got that head up display. So everything that's under the most question and selected will get info displayed in the top left corner. For example, when you're over a symbol it just displays the description of the part in the link to the data sheet you can just click on and you will get right to the data sheet. And for example, for pads in package editor you will see the pads parameters like width and height. And if you select two of them, it will show you the distance between those. So if you want to figure out the pitch, just select two of them and you'll see it right there. Don't have to look into each pad separately. So another feature that turned out to be really useful is a copying of placement and tracks on boards. So even though modern ICs are one more integrated and they're less of them, they happen to require many different power supplies. For example, on this board alone all the blocks that are in red and even some more are just voltage regulators. These have the property that they are all basically the same, just different values. And you don't want to do the layout for each of them separately for what you want to do is layout one and then apply the tracks and placement you did for that one to all the other ones. So on the horizon it's done like this. In the schematic you specify groups and tags. So a group would be one voltage regulator and you then, so the yellow one. And the tag specifies the models like local reference designators. So horizon knows which component, maps to which component in any other group. So that way you do your board layout for one and just place the main component. For example, the switching regulator I see on the board and just place all the other components somewhere. Then you select all of them. And then tell it to copy the placement from the already routed section. And then you're there with basically just one tool. And when you've done that, you select the tracks on the left side and tell it to the right side. And then you're there. And that process makes it really easy to do repetitive stuff like voltage regulators or other things that don't really need hierarchical design. And the hierarchical design is still yet to come. Since there hasn't been any project yet that really required it. But there have been even more things. For example, you've got an incremental search like in every modern text editor. Also some nice features like smooth zooming or fully customizable keyboard shortcuts and colors. So you aren't stuck with my choices anymore. And also performance improvement like DRC that makes use of all available threads. So what's next from this point? So I've been working on Ryzen for a bit more than two years from now. And it's been used in my master's and some other projects. And some people told me, yeah, it's already really usable. And I think a Ryzen is appropriate. And so I don't have a really fixed time for that. But I think all the features that are features to use it for designing actual boards are there. And so one of the things to do for that release are to improve the out-of-the-box experience. So new users get gently introduced to the kind of complicated concept of the pool and user documentation in that regard. So here are some links to the project and to the reference design I did. And thanks to all the people on the internet that helped testing it and submitted bug reports and patches. And that's it for now. And now it's up for questions. There were recent walls and packages from other EDAs? Yes, I do. So the plan was whether I have plans on doing import features for other application file formats. Yes. So importing packages, for example, from Keycard, would be a quite natural fit, since the definition of a package doesn't matter. So isn't all that different? And importing symbols is also doable, since the symbol contains everything that's needed to build a part in the horizon. So using an already existing package plus a Keycard symbol would result in a part. And so it's just work. It's not hard, but it just has to be done. In the off view, you said that you only have real parts. Yeah. But I often just specify 0603 1K, and that's it. Then later on, we'll figure out which of the about 1,000 available ones I'm going to buy. Do you support that, sort of like a generic part? Yeah. OK, so the question was whether there's a way to specify generic parts, since the pool should only contain orderable parts. So Octopart has that thing called the CPL, the Compart library. And in there, they have that naming scheme for like passive, like a CPL 1K or 0603 0.1 watt. And I already imported these into the pool. And if you happen to use Octopart for your bomb generation, then Octopart will resolve these into an orderable part. So the question was how parts just on the PCB are handled right now. Right now, they aren't. So test points, so in my opinion, you also have to appear in schematics. So you know where it should be logically. And things like spark caps should, in my opinion, also appear in schematics. So these should also be included in the pool. But still, there's an option missing to make them not appear in the bomb output. The main reason for this is that no one has asked for it yet. OK, so the question was whether there's support for plugins. Right now, there isn't any. Since that would require some of the now internal APIs public. And since the project is quite in its infancy, that would restrict my ability to make easy changes. So I don't have any plans to introduce a Python plug-in API for now. But if it becomes necessary in the future, then it might happen. OK, so the question was on the stability of the file format. So the file format has always been quite compatible in that way that you can always open all designs. And the ability to read those designs will likely stay in the horizon for a very, very long time. But as you save that file again, it might not be readable correctly by older versions. But there have been some small changes, but nothing that makes your design unusable. So right now, it's just a number. So right now, I think there are four internal layers defined. But upping that number to 32 would only require small changes. And I think I might be limited to what KCAD supports right now, since I used the KCAD interactive router and have to map my layers to their layers. And if they don't support more layers than that, yeah, that's it. Yeah. So there's definition and authority. OK, so the question was whether there's support for bus definition and bus routing. So bus definitions are supported. So they're actual buses, not just names in schematic. But bus routing isn't supported since all of the routing stuff is pretty much just the KCAD router. And KCAD doesn't support bus routing yet. But if they happen to add it, I like to adapt it as well. Yeah. The rule is some rules. How does this software suggest such things like PCB drawing, line tracking? OK, so I guess the question was about design rules. OK, so Horizon supports something that is a bit designed like the rule stuff in Altium. So you can have many instances of the rules. Each rule has some criteria that it matches on. So for example, you can match either on net name or net class or regex that matches the net name. And so for clearance, you've got two matches. And if these two matches match, then that rule, for example, like distance will get applied. And that distance rule can specify the distance between like track to track, track to wire, track to a pad, track to mortgage or something like that. OK, so the question was, what's to do with parts that aren't orderable? So those pools in Horizon support inheritance. So you can just create your own pool, define your personal stuff in there, and then tell that pool to include the global pool. And then you can just have parts for yourself.