We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Horizon EDA - Version 1.0

00:00

Formal Metadata

Title
Horizon EDA - Version 1.0
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This talk covers my motivation for starting a new EDA package in 2016 and the main ideas behind horizon as well as what has changed in the last year. I'll also go into my short- and long-term plans for the project. Horizon EDA is a from-scratch EDA package with focus on useful parts management, rule-driven design and good usability. It has already proven its suitability for medium-complexity projects in the board design for my master thesis and in various hobby projects. This talk covers my motivation for starting a new EDA package in 2016 and the main ideas behind horizon as well as what has changed in the last year. I'll also go into my short- and long-term plans for the project.
Figurate numberRoundness (object)Event horizonExploratory data analysisPoint (geometry)Computer animation
Revision controlEvent horizonExploratory data analysisMathematicsHierarchyDirected setTexture mappingLengthImplementationLibrary (computing)Data managementSoftware developerRevision controlPoint (geometry)1 (number)Decision theoryMultiplication signUsabilityWhiteboardRobotConnectivity (graph theory)CodeComplex (psychology)Software bugDampingImplementationSymbol tableData modelSocial classCore dumpFinite differenceUser interfaceText editorProjective planeMappingMereologySinc functionHierarchyEndliche ModelltheorieLine (geometry)CuboidInterface (computing)Computer animation
Text editorVolumenvisualisierungData typeRobotSymbol tableMultiplication signWindowText editorComputer programmingWrapper (data mining)PlanningWikiState of matterProjective planeWeightGraphics tabletProcess (computing)NumberBitSource codeExecution unitWater vaporRight angleBoss CorporationRing (mathematics)Twin primeComputer animation
VolumenvisualisierungText editorMereologyMaß <Mathematik>MereologyText editorExecution unitPersonal identification numberComputer animation
Maß <Mathematik>Value-added networkMereologyRule of inferenceSoftware frameworkText editorRobotProjective planeFormal languageBitSinc functionData managementGraphics tabletStack (abstract data type)Point (geometry)WhiteboardPolygonLibrary (computing)Parametrische ErregungDifferent (Kate Ryan album)Computer animation
Rule of inferenceRectangleSoftware frameworkInformation managementWhiteboardGraphics tabletStack (abstract data type)Type theoryDimensional analysisProjective planePoint (geometry)Product (business)WhiteboardGoodness of fitMultiplication signWater vapor2 (number)Router (computing)PlanningView (database)Line (geometry)CodeText editorData managementLibrary (computing)Element (mathematics)INTEGRALSource codeComputer animation
WhiteboardWhiteboardProper mapView (database)PolygonLine (geometry)CodeRow (database)Computer animation
Endliche ModelltheorieTriangleHypothesisView (database)CodeProjective planeCovering spaceMessage passingReal numberComputer-assisted translationTransmissionskoeffizientComputer animation
Function (mathematics)Digital-to-analog converterData conversionProjective planeComplex (psychology)Field programmable gate arrayFrequencyReal numberQuicksort
HypothesisGraph coloringSinc functionPoint (geometry)Projective planeCartesian coordinate systemConfiguration spacePolygonData managementMaterialization (paranormal)Computer animation
Probability density functionDatabaseGraph coloringRevision controlPolygonCategory of beingContent (media)Computer fileDisk read-and-write head19 (number)Rule of inferenceOcean currentRight anglePoint (geometry)MathematicsState of matter2 (number)Numbering schemeMultiplication signTriangleImplementationProper mapTable (information)Probability density functionParametrische ErregungSinc functionBitSimilarity (geometry)Presentation of a groupMereologyInformationWeb browserFocus (optics)Computer animation
UsabilityProjective planeImperative programmingSoftware developerMereologyCuboidOpen sourceRevision controlSinc functionSoftware bugComputer animation
EmailOpen setAreaNumberFlow separationSoftware bugControl flowSoftware developerCompilation albumLocal ringMultiplication signProjective planeInterprozesskommunikationTheory of relativityLinear regressionoutputCartesian coordinate systemCASE <Informatik>WindowEmailWhiteboardSoftware testingForcing (mathematics)Uniform resource locatorComputer animation
Computer configurationLibrary (computing)Element (mathematics)Human migrationState of matterMultiplication signArithmetic progressionPrice indexTrailEvent horizonExploratory data analysisWhiteboardBitSymbol tableCodeIntegrated development environmentSoftware developerPlanningFile formatProjective planeMereologyDependent and independent variablesSoftware bugRouter (computing)Sinc functionLengthSlide ruleStudent's t-testDecision theoryDuality (mathematics)Well-formed formulaOrder (biology)Right angleWater vapor1 (number)Automatic differentiationSource codePRINCE2Link (knot theory)Presentation of a groupInformation technology consultingComputer programmingWeb 2.0Computer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
Okay, for our next talk we have Lukas Kramme who will be talking to us about Horizon EDA. This is our fourth EDA package of the day, you should consider yourself incredibly fortunate and let's hear a round of applause for Lukas.
So welcome everyone to my talk on Horizon EDA. So for those who don't know yet, Horizon is a full-featured EDA package for PCB design, it does everything from library management to schematic entry, PCB layout, and 3D export.
So this talk marks the release of version 1.0 after about three years of development and I'd like this talk as an opportunity to take a look back and see what decisions drove the development in the past three years.
So when starting I had to make a few decisions upfront that would ultimately guide the rest of the development. So first and foremost was keeping it simple since an EDA package of that size is something inherently complex. So most of the work was basically keeping complexity low enough.
So that meant not having any funky class hierarchies in the core data model since, for example, mirroring a symbol and mirroring a package on the board is something that takes very different operations. And keeping simple also meant keeping a direct mapping from the user interface to data.
I think that if the user interface and the data model are aligned then that really helps to keep complexity down and avoid bugs in that regard. Since I was starting from scratch I decided to do a breadth-first implementation to basically
implement something that's usable for all aspects so that I could validate my architecture and get feedback early on. So I didn't develop the schematic editor from start to finish and then think about the bot editor. I developed a minimum viable version of every component first.
That also implied not being afraid to rewrite stuff since that project is a learning experience for me. The code that was written some time ago now isn't that good anymore since I now know more stuff.
And last but not least, having fun is also an important part since I'm not getting paid for this. I'll have to keep myself motivated and having fun is the best way to do so. So that's wrapped the time back to September 2016. That's when the first commit happened, not public yet.
At that time I decided to write the program in Python and see for the OpenGL rendering since that's what I knew at that time. And I started with the simple editor since the plan was to have more of the same editor for everything from symbol to schematic and bot and so on.
And symbol was the one that had the least dependencies. That went for about a month or so until I got fed up with Python's weeks typing. So I decided to scrap that and rewrite everything in C. It only lasted for about a month as well since I then got fed up by GObject since I used GTK for the UI and tried to
parse my own data type through a GObject callback and I just couldn't be bothered to do this. So I decided to give that C++ thing a try and was pleasantly surprised. So in November I got the symbol and schematic editor done. And at that time the schematic editor already had all the stuff it has today like knowing
about nets and buses and so on. So pretty good actually. Then in December 2016 everything that required layers like pad slack package and bot came. And I also made it to run on Windows which mostly involved some wrappers for UUID stuff.
And on that year I met Rafael from the LibrePCB project, he's also here. And I talked about the project with him since I saw LibrePCB on the congress wiki that year. And he encouraged me to release it since I was a bit hesitant due to the early state.
In January 2017 I cleaned some things up and wrote text editors for some of the non-graphical stuff like entities and units that define the pins of a part and put it on GitHub.
And so that's what it looked like back then, the schematic editor. So many things are still that way today and the bot editor as well. So the first thing that happened after the release was adding a project manager. Since back then you had to launch each editor from the command line which was a bit inconvenient
for many users. And in May 2017 I then added a DRC since you basically can't live without DRC if you want to do an actual board.
And my approach for doing this was to just dump the whole board as polygons and then use the excellent clipper library to just offset and intersect the polygons and that was a pretty easy and correct way to get DRC running. Then in June 2017 I added a parametric pad stack, pad stacks and packages since up until
that point. You had to draw each pad stack individually so if you wanted to have a pad of a different size you had to redraw it and I solved that by adding a small stack-based language that modified the pad stack in place so that the user can just type in the dimensions as usual.
And September 2017 was a pretty big month since I added the pool manager that allowed for managing all of the library elements without CLI at all and I also managed to integrate KiCad router which was about 2,000 lines of code on my side and like 20,000 from the KiCad router.
And so that was a pretty good return of investment since the KiCad router really helps to make the board editor actually usable for actual projects. In October then came copper planes and a 3D view that at that time only could show
the board without any packages and that was mostly driven by me wanting to do OpenGL the proper way so actual 3D than just the 2D board rendering for schematic and board. And that view just works by dumping the board as polygons and triangulating them
and rendering them so pretty basic stuff. I think it was also less than 2,000 lines of code. Since the 3D view is pretty much ornamental without packages showing, I added step import and end export and for the import I used the code, the open cascade with the code
from KiCad to use open cascade to triangulate, to convert a step model into triangles and then render that and the step export was adapted from KiCad to step.
April 2018, then saw the start of a master thesis which was an X-plane transmitter, so a moderately complex design with FPGAs and D2A converters to differential pairs and about 10 gigahertz in output frequency. So that was the first real world project that was also not too simplistic.
That then motivated me to speed up DRC by making it multi-threaded which was pretty easy since DRC just involves intersecting polygons and there are quite many of them so just spawn threads and let them do the work, that helped a lot.
And I also added export for bill of materials and later in that year I unified the pool and project manager since users were happy that they had two entry points for the application and now we only have one application, they then click on the desktop as they expected. And October 2018 also configurable colors since users were complaining about the color
scheme not suiting your preferences and I didn't want to force my taste on everyone else so I decided to make it configurable so that could have helped so users might wish for that earlier but it was one of the things that wasn't that much fun so it had to wait for a while.
January 2019 then saw some other improvements such as parametric search in the pool since with that many passives in there you will need to have a proper way to search for them and my approach for doing this was to add a parametric search at you as you know it from
distributors and so you can search capacitors by value and tolerance and so on. I then also added a proper pdf export, actually pdf export has been in there since more or less day one but that just exported what was sent to OpenGL so if you had a polygon you got triangles in the pdf and the new pdf export actually exports polygons and also
makes text searchable and adds a proper table of contents so you can easily navigate your sheets and I also added the incremental pool update since if you changed something it had to rescan all the files to update them into the SQLite database and that took 10 to 15 seconds each
time you edited something and with that change it just updated what actually changed since for the first implementation the focus was on getting it correct and not fast and then I decided to add more speed with that one. So in November 2019 I then added the part info API
from kidspace so that you can see the stock at DigiKey and other distributors right in the part browser so you know which parts are actually on the shelf that's especially important for
passives where there are quite a lot with similar specs and you want to pick that one that has the most stock and last but and so now we are at the present date in January 2020 or February where after exactly three years since the public commit I released version 1.0
and so since we are now at the current state I'd like to talk a bit about something else namely taking care of dependencies since pretty much as every other open source project
Horizon EDA wouldn't have been possible without dependencies and I think it's an imperative for every open source developer to treat the dependencies as part of their project since if the dependency has a bug and users complain to you you can't tell them it's the
dependency's fault they want you to fix it. There are actually quite numerous bugs that got fixed as a direct consequence of my development on Horizon EDA so the most important one that a GTK is open GL area which I rely heavily on for displaying
schematic boards and basically everything broke in very strange ways when your application had one then more window open that had a GL area in them took quite a while to debug but eventually fixed it and another Windows related thing was was libgit2 that had a regression that broke
that made it make a tech fault due to re-order input path that was also quite interesting to debug and a rather odd bug was that zero MQ which I use for for IPC I decided to use the current locale when formatting port numbers so when the current locale
at that time was set to to a locale that had a thousand separators the port number would include thousand separators which would then break everything and yeah that was that was also quite easy to get fixed and I'm not at that direct dependency but I noticed that
ccache which I use for speeding up compilation stop recognizing the headers and that was also a regression that got unnoticed but was also quite easy to fix and in general my whole experience and dealing with other projects was quite positive since I am I was always able to provide
a very concise test case and that that they were easy to fix so you might be wondering what's next that might be a bit unexciting since my development is really is will go will go on as usual with with no really big bang big bangs plan so far so it'll so I'll do what's on my mind
and what and what users suggest and that's it and now we have time for questions
so the question was how I imported the bits and pieces from kiket I use I just copy pasted their code in there and made a few adjustments to make it compile in my environment
but it's not linked in any way so I'll have to update it manually and there also was related to that there was a bug in the router that made it not recognize large clearances
I noticed that bug and it took me it took me a few hours to fix it the next day I had a look at at kai kart's computer and and found that they fixed the bug a few months ago
yeah how have users responded to your policy of only including orderable parts in the library okay so the question was how users have responded to my policy of only including orderable parts in library for the response have been a bit mixed somewhere somewhere a bit some some found it a bit too a bit too restrictive
but but I think it it really it really makes a bomb export a lot easier yes so so since I am from stuttgart and there okay so the question is if there were any
projects projects done with it that weren't done by me so uh so at stuttgart there's at the at the dual hochschule there's there's um there's a formula student team that built that built electric race cars and since a year or so they're using horizon eda for their
board work so what what should kikad look to import from horizon copy and paste from the work that you have done that does not yet do so so the question was what what kai kart could learn from horizon eda
so i think that's a bit of a difficult question to answer since my decision for not working on packets and starting my own project was like that i wasn't as same as same as with library i wasn't satisfied with the library concept and that's something that that that you pretty much can't import since it's the very foundation of the program and if you
change that that wouldn't be kikad anymore and so so some things that might be so as kemen suggested might be the length tuner i i don't unfortunately don't have a slide for it but it gives you a represent it gives you like a progress bar like indication of many of many
tracks so that allows you to easily tune differential buses so the question was if there's
a migration path to import tikai projects unfortunately not so but what you can import is packages so so since that project at the current state mostly mostly developed by me and my time is limited so i think i i can spread my i can spend my time otherwise that's more
productive so i think it's most so the question was what third import options are on the roadmap so i think what makes most sense is to import library elements like symbols and packages
so right now the package import works quite well and and i'm looking into doing the doing a simple import so kikad would be would be the biggest option since their file format is pretty reasonable