The best thing to happen to KiCad was skidl [1] paired with freerouting [2]. You can spin a board in so little time it's insane. In the future I will be looking to automate even the parts placement too.
P.S. If there is interest I will look to document my workflow.
Ehh, more than 90% of my time making a board is in reading data sheets & Application notes, making a schematic, component selection, component library building, and part placement. Routing is the easy part and relaxing enough that I like doing it myself.
Sure, some parts are obviously a manual process and hard to automate. But this is about automating the parts than can be automated.
It would be like suggesting that there is no point having LaTeX perform typesetting because the research takes so long anyway and you like typesetting your documents. I personally would rather spend that time doing something else and let the machine get on with it.
No, that's a bad analogy. A circuit board is not something that gets re-built every time you make a change. You can't just arbitrarily run traces around a board and expect a working design that meets EMI/EMC requirements.
I'll coin a new term here to classify this kind of problem: NP-incomplete. A problem that's known to be NP-hard, and is actually now impossible because you the program doesn't have all the information it needs to solve the problem.
To properly route a board, the tool would need to know what kinds of loads are at each end of a net, how thick the trace needs to be, where the return path for the current loops involved are, the edge transition times of all signals on the board.
You have to know not to route delicate high-impedance signals next to high dV/dt power traces, how to properly split and combine ground planes, how to respect creepage/clearance requirements for voltage isolated systems, etc.
About the best we can do today is to use autorouting for not-so-critical traces after the work for everything else is done, and even then it only really works well when you have PCB area to spare. In the worst cases, like some 2-layer boards, an autorouter will inappropriately chop up your ground plane with the traces it needs to route and turn what was a good board with solid return paths into a poorly routed mess.
The reason autorouting sort of works in VLSI devices is because all of these requirements are baked into the tools themselves. Every signal has a timing requirement, an impedance requirement, fanout limits, etc. When you are only dealing with digital logic, it makes the job much easier.
Interesting. I used to program CNCs (lasers and punching machines) for automotive parts. We couldn't rely on the path planner either. If the punching machine's turret ran too close to the clamps, it would crash and put it all out of alignment. There goes a day of production. The planner assumed all material was rigid, but when perforating thin material that wasn't the case. You'd end up with corners bouncing up into the turret that get caught and crumple the sheet metal like paper. The third issue happened when the auto path wanted to change tools multiple times.
It turns out that manually programming paths to account for those issues actually generate hundreds of saved production hours per year.
I agree. PCB layout itself is pretty fun and easy to do manually for any hobby sized projects. Making components is the tedious part. I wish there was some kind of standard component format that could be embedded into datasheet PDFs or something. Maybe as a QR code.
> Ehh, more than 90% of my time making a board is in reading data sheets & Application notes, making a schematic, component selection, component library building, and part placement.
With 80% of my time being just the data sheets, application notes, and component selection.
It's really remarkable just how little time I put into the actual mechanics of building a PCB vs. everything prior to that.
What kind of boards are you making? I used skidl a lot but I ran into two challanges, wondering if you have run into these also:
1) There was no easy way to combine schematic and skidl-based circuits. This was a problem at a company environment where design reviews become impossible because nobody else could write their heads around a power converter circuit made in skidl.
Ideally I would have wanted to be able to drop in a "skidl-block" that would just have a fabric of a bunch of digital connections, and let analog circuits remain as graphical schematics.
2) I really like KiCad's backannotation feature for adjusting BGA fanouts and whatnot from the layout. It is really fast and makes doing layout much more pleasurable (that is a standard feature also in all the big name commercial ECAD suites). Using skidl broke my backannotation flow, at least that was the case ~6 months ago which is the last time I used skidl.
Boards with power circuits and micro-controllers. I'm not sure I would trust the routing software when it comes to a high-speed bus or radio just yet.
> There was no easy way to combine schematic and skidl-based circuits. This was a problem at a company environment where design reviews become impossible because nobody else could write their heads around a power converter circuit made in skidl.
> You can output a schematic
I've been working on a branch of SKiDL that outputs schematics that can be directly opened using KiCad's EESCHEMA. That will allow some capabilities SVG figures don't allow.
I'm not really sure who the target market for things like skidl and jitx is: people who think schematic capture is a laborious, tedious, and error-prone technique for entering data before you can get started on a layout, instead of a useful documentation step that will yield dividends over the lifecycle of your design?
The jitx folks used to talk a lot about making test jigs and adapters for people, which is a simple enough application that a text-based system could really shine at.
I genuinely applaud any file format that can be diffed, but skidl seems like an absolutely painful way to develop a circuit - unless you already have a schematic (which seems redundant). Freerouting seems like a good way to iterate quick solutions to routing approaches, but obviously has a lot of limitations.
There is a generate_pcb() function in SKiDL that will output a kicad_pcb file that can be directly opened using PCBNEW (no need to generate the intermediate netlist file). That function uses HierPlace to group the parts based on their hierarchical organization. That would be a good place to inject some autoplacement if you get it figured out.
As a software guy who occasionally does a test or automation fixture, I find the workflow of most EDAs a bit strange. It seems to actively discourage reuse.
Everyone seems to have their own stash of footprints and known good circuits.
Yeah, because making a good footprint suitable for upstreaming is so laborious, and categorizing it is just as important as making it in the first place, most folks who find themselves needing a footprint just whip one out for the job at hand and it's "good enough" and they reuse it forever, even though they'd be ashamed to share it.
I'd love a Footprint Club that looks at what people have been making for themselves, accepts submissions, and cleans them up the popular ones for upstreaming. Hmmmm.
No, there needs to be a footprint standard library. Three dozen or so standard footprints, drawn rigorously to standards, will cover tens of thousands of parts. (I'm talking things like EIA/IEC standard chip parts, JEDEC and JEITA transistors, diodes, and ICs, etc. Connectors not included!) Make that, rigorously and with documentation and traceability, and you can design boards fast and with great confidence in their manufacturability.
Unfortunately even professional EEs struggle with using standardization to their advantage, I have found. Partly this is vendors' fault as they don't make things clear at all. Partly it's just a nice competitive advantage for me and my employer as we spend far less time on footprints and have far fewer footprint errors, so I guess I shouldn't squawk too loudly....
There is a standard library and it's quite good, but manufacturers just puke out special footprints for any random thing. Often for good reasons, but often not, and it really doesn't matter if you need one in your design. You've just got to make it, period.
Is it documented and traceable now? It didn't seem to be last I looked, but I admittedly didn't look too hard (I've been using Altium for years). This is critical for a standard library: parts need to be compliant with standards (usually IPC-7351 plus the mechanical standard for that part), they probably need to be put on a grid (and it should be the same grid for all parts), and things need to be documented to the point that I can trace where that footprint came from, why it has the dimensions it does, and what it's good for. None of this is all that nasty, but it's the difference between "Footprint Club" and "Standard Library". Oh, and you probably need to record usage, since something that's been hand-assembled once is very different than something that's been used in production a couple million times.
> manufacturers just puke out special footprints for any random thing
Tell me about it! That said, familiarity with the standards will let you conclude that many things that look like they kinda-might-be standard but aren't obviously listed as such actually are standard things. This is key to saving time with a real standard library. (Diodes are the worst offenders here. The worst.)
> You've just got to make it, period.
Also known as "the refrain of the connector". Fuck connectors.
There are parts libraries if you work in a company (there would be a whole division devoted to building components) so that internally there is a ton of (mandatory) reuse.
> As a software guy who occasionally does a test or automation fixture, I find the workflow of most EDAs a bit strange. It seems to actively discourage reuse.
Being able to re-use Python code sections is obviously quite cool.
I don't yet have a good solution to footprints, but slowly but surely getting there with the tooling.
I love KiCad. Best part is that I can run a pipline in gitlab [1] that will produce Gerbers for specific fabs, automatic rule check as well as interactive BOMs exports.
Additionally the 3d export is good enough now that you can import it into Blender and do something like this within a few hours: https://www.youtube.com/watch?v=svU7NyfJJKY
Yes, I think this is undervalued feature, which should be used more in professional contexts.
- being able to tag a commit, which automatically updates silkscreen with tag name/board revision and commit date.
- being able to run automated checks on outputs (are part numbers defined for all components? are they valid? are they in stock?)
- not being able to produce outputs if DRC fails (I have messed up real bad by exporting gerbers in Altium with shelved polygons)
- all of the outputs are produced at the same time (I have messed up with re-exporting gerbers but not BOM)
- making sure that design is atomic/does not depend on libraries present only on a particular machine
I recently went one step further and set up CI job to check symbols in my personal library using kicad-library-utils (which performs the same checks as for the symbols in official kicad libraries, which ensures consistent style and allows for custom checks (e.g. MPN/Manufacturer fields present).
JLCPCB and other Chinese fabs really revolutionized the hobby PCB market with their automated systems. Hope we will see fabs based in NA or EU doing the same. I'm tired of waiting a month for the boards.
The 3d export function is amazing, export to 3d cad software and built housing around it, or see if it will fit in an already designed enclosing/design/object.
I etched PCBs with my dad when I was a kid (a long time before the Internet), and delved into electronics very early on. I loved SPICE and all the other DOS-era tooling we had, but am still flabbergasted at the breadth of scope of KiCad and what you can do with it completely for free. It’s like Christmas every day for those of us who still dabble in electronics for fun.
I really hope kicad gets the blender treatment some day. It has been a dream of mine to actually not have to use altium(or eagle, or orcad) when working for an EE company.
As someone who used/attempted to use Kicad in 2009 (it was introduced as 'another option' in my electrical engineering coursework alongside Eagle - long before the latter was acquired by Autodesk), it has received the Blender treatment. It has trivial all-in-one installers for most platforms, a decent standard library, solid documentation, very few bugs... it's as easy to use as Eagle today, which was not the case in 2009.
Being taken seriously by companies, getting the big investments to increase developement speed by lots. Actually overtaking its competitors in terms of features. A big usability overhaul. Fun stuff like that.
Having worked in the EDA industry, though more on the electronics simulation side, there's a surprising amount of complexity in these tools. I think the complexity is such that it needs more than a single entity supporting it otherwise only the features that CERN directly uses will get enhanced.
Can confirm from the plugin simulation side. Integrations and import/export are important. Drafting by itself is useless to many companies without facilitating the corresponding engineering work.
Agreed! The data challenges are the biggest blocker IMO. It's so hard to know the quality of models even when received directly from manufacturers. Hopefully companies like SnapEDA can help with a lot of it though I think there needs to be some kind of model interchange standard
SnapEDA is a pox upon the industry attempting to be yet another middleman in between you and parts libraries.
Unfortunately, companies like SnapEDA bring negative value to the industry because they produce crappy libraries that you can't trust.
So, they reduce pressure on the parts vendor to produce a decent symbol/model. At the same time, I can't trust the symbol/model until I check it personally and run it through a project. And, finally, some contract terms generally prohibit me from redistributing that symbol (go check the terms you agreed to when you signed up).
I had some really bad issues using vendor supplied (TI even!) and snap parts with misnumbered pins or the wrong width package... and many bad experiences with eagle built in libraries.
I much prefer using a formula based tool to make packages for a specific part's mechanical drawing, I just don't trust what other people have made yet. I'd like to be able to but the trust isn't there yet.
Maybe kicad could list parts as verified against a standard footprint based on user feedback so that I know that whatever random part number actually fits this particular soic wide or whatever bga pattern. Maybe a part number has no notes but it's nice to know that no one has checked it manually yet too. Like the wine database.
That is great and all, but I am an EE student, and last time I looked for an internship, there are a grand total of zero actual serious EE companies that use kicad. It is pretty much all Altium rn (and god I hate using altium). So ye, what I mean by being taken seriously by companies, I am talking about more than one or two companies.
On top of the other answers: a much more friendly UI. Blender used to have a horrendously steep learning curve because the UI was just alien and ignored most agree-upon convention used by other 2D and 3D packages.
Not the case anymore, Blender is much more user-friendly and beginner-friendly.
The huge amount on online video tutorial also helps tremendously.
It was really not that bad, it just looked scary, once you got past the first steps, it was fine. But I guess those first steps made a big difference in adoption
What I tend to recommend folk do in the synth-diy community is to find existing designs like Yves Usson's yusynth stuff, and make a "cover version" of it. Draw the circuit diagram, and from that draw the PCB, trying to keep them as close as possible to the originals.
That way you're climbing the "using the tools" learning curve separately from the "laying out designs" learning curve, which makes it all a lot easier.
A lot of small things, for example editing multiple parts at the same time (select multiple parts, E, change, lets say the value of multiple resistors, enter). Or how the power ports are horrible to use (you have to create a new symbol for each new net (these should really just be some sort of global label, with a power icon). Or a better, iso standard footprint generator. Being able to have multiple sheets open at the same time. Just small things like that.
As for the UI, actually, just steal the blender UI concept, that modular window concept is great, though, if you define "user friendly" as, "The user immediately knows what to do when they open the program" idk what would help with that, it seems pretty on par with other pcb design tools in that aspect.
Altium is like the Solidworks of ECAD. Intuitive enough to pick up pretty quickly and you can get pretty far with it. It's also frequently buggy and the company is not responsive at all, if you file a bug report you're lucky if they fix it several releases down the line. Hope you paid the thousands of dollars for the support subscription.
Orcad is, I dunno the Catia? Was the "serious" software back in the day so preferred more by greybeards who scoff at using amateur stuff like Altium. Interface is much more dated and less intuitive. A company I worked for had a mild mutiny because they hired an Apple guy that insisted that everyone learn and switch to Orcad and the EE team just balked at it.
If Kicad can catch Altium on usability and handle dense, complex boards then it could be the best package out there. Just the fact that they actually fix bugs puts them at an advantage. They may already be there, I haven't played with it in a while since I'm at an Altium shop.
Love KiCAD and used it to make single and 2-layer boards around 2014.
One niggle was if you had an unusual component it was not much fun to
define new one, binding together the schematic symbol and footprint
into a package, dealing with unused pins and labels etc. Eagle seemed
to have more professional component libraries. Anyway I expect that's
improved in the past 8 years.
It's still not fun, but I'd put it on par with Altium Designer:
+ at least I don't have to generate my own bog-standard 0402, 0603 resistor/capacitor footprints,
+ a lot of the standard IPC-something footprints are included in kicad standard library (e.g. SOT23, SOP8, etc)
+ you can easily copy an existing transistor symbol, assign it a particular footprint you've verified and save to your library).
- Altium has a lot more built-in wizards for symbol and footprint generation. There are some online kicad symbol library generators and a few built-in footprint wizards, but I believe AD has more.
The Altium online component library probably does provide a larger selection, but I personally don't really trust it to be around forever. I'm also not sure if you don't need an active altium subscription (5000-8000USD/yr/seat) to have access to it.
This is what keeps me from using Kicad also. In my opinion creating custom components is the #1 thing pcb editors should focus on, but most freeware or libre pcb editors assume you'll mostly want to pull parts from a standard bank. That's fine, but I like to customize my footprints and also carefully validate them against the manufacturer datasheet.
I've used KiCad for 2 and 4 layer boards, including RF-sensitive stuff with PCB antennas, worked great. Loved that the component footprint (among other things) was just readable text, thus I could manually create the traces for the antenna exactly per the TI appnote describing the antenna, which was much easier than making the traces by hand in the editor.
When the autorouter was removed, I lost interest in working with KiCad.
There are published excuses for why you don't need/want the autorouter, but they read like fanboy stuff.[1] The removed autorouter can still be run, but the integration isn't very good.[2] It's too bad they gave up instead of improving the autorouter. It wasn't that bad.
It was interesting how hostile the professionals on the reddit thread were to autorouting.
They mention a host of things that the autorouters are bad at as evidence that autorouters are useless, instead of recognizing the opportunity to improve autorouters to make their jobs easier.
The 'travelling salesman' argument was my favorite though, because it's somehow okay for a human to provide a working but non-optimal solution, but the bar for the computer is finding the optimal solution.
It's probably because most people who come into PCB design assume autorouting is like a compiler: you just need to design the schematic and then the computer does the rest for you. Even with very good autorouting this is never the case, and if you assume so, especially as a beginner, you will wind up with hilariously bad results. This is why experienced PCB designers will often smack the beginner's hand away from the autorouter.
That said, they aren't completely useless (though I've never had a case where I needed it), but they are also a very high effort to improve: it's a thorny optimisation problem to start with, but also what is not appreciated is it's also a really difficult user interface problem, since the designer needs to be able to specify the requirements to the autorouter in high precision enough to get a good result, while also taking less time than just doing the routing themselves (which for experienced PCB designers is not really that long for most cases), especially when placement is just as important for a good result, intermingles with routing to a large degree, and is even harder to specify (placement depends on finding a good compromise between thermal, electrical, and mechanical goals, all of which are difficult to specify precisely).
Given they're a big trap to newcomers and also a huge amount of effort for something which has pretty niche applications in practice, I'm not suprised the team behind KiCAD decided it was not worth the effort. If you (or someone else) thinks they can make a more useful one, it's definitely a space where improvements on the current state of tooling can be improved, but don't underestimate the effort involved.
What specifically are most autorouters bad at? My understanding is that most autorouters are simply using bad algorithms and miss optimizations that a human could spot easily. I was recommended to try this autorouter https://www.eremex.com/products/topor/ but I haven't got round to trialling it yet.
>The designer needs to be able to specify the requirements to the autorouter in high precision enough to get a good result, while also taking less time than just doing the routing themselves
Aren't most of those rules the same between projects. Once you have a good setup you're good to go on many projects?
A lot of the routing work is in the placement, setting up components to make the routing as trivial as possible, and the autorouter isn't doing that for you. I don't think it'll do pours either but I haven't used one in years. If it's a simple board with just some power lines and digital signals the auto-router will probably do ok, maybe faster than doing it by hand if you can reuse most of your rules. But if the board is that easy an experienced layout engineer would also make short work of it.
Now what if the board is more complex? You have some sensitive analog signals, high speed digital signals, and some RF stuff that. Do you take the time to set up a room in Altium with special rules for the RF stuff? Make some complicated rules so that the high speed digital would mess up either of the other things I mentioned? Could be done, but the trial and error of getting all the design rules right is probably more work than just doing it.
The problem is that easy stuff is easy, and doesn't need an autorouter. Hard stuff is still hard with the autorouter and unlikely to save that much time. It's hard to find a use case where you come out ahead. Maybe a board with a massive amount of GPIO and nothing else?
Back when I used Eagle the "oh boy that's so many pins of signals I care so little about" was pretty much the only time I found their autorouter somewhat useful. The remainder of the time I was annoyed because Eagle being essentially just a vector-drawing program doesn't have (or didn't, at the time) push & shove routing which made tweaking layouts so goddarn annoying, in particular because the tools to move stuff around were completely trivial (i.e. they just moved the selected vertices and made no adjustments at all). KiCad is imho way better in almost every way than Eagle (in the versions I am familiar with).
I had that with the autorouter. I was doing a board that had one critical area, a custom switching power supply. The rest was slow signals. The switcher area had to be given a little extra space and some obstacles so the autorouter would do a tight job there. For the rest, whatever the autorouter did was fine.
I, too, am amused by how wound up some people get about this. It's a tool.
Autorouters are generally bad at: routing related signals together (often important for performance), routing power (especially high current traces), prioritising sensitive signals, keeping sensitive signals away from noise ones, and often somewhat suprisingly coming up with any solution at all or coming up with a solution that passes the tool's own design rule checks. Some of this is bad algorithms but a lot of it is because the autorouter is not given enough information. You can specify some of this to most autorouters but it's not super easy, and that information does usually change between projects. That's part of why I think improving the state of the art is in large part a UI problem.
Another big part of why the autorouter might underperform is it's entirely subject to where you've put the components, whereas a human will generally do placement and routing in parallel to at least some extent. Placement is if anything the harder problem in PCB design and there's no systems currently that really combine the two operations (there are auto-placers but they're generally even worse than autorouters, for similar reasons of the requirements are complex and hard to specify).
In general these kinds of systems run into a bit of a catch 22: in order to use them well you need to have enough experience to do the job yourself, and be able to effectively evaluate the output. But when you have this you find it's faster and easier to do it yourself. And expecting it to be helpful for beginners is a bit like expecting github's copilot to be a shortcut for beginners: the tool is going to throw out bad results sometimes and the beginner is not going to be able to evaluate that or know how to fix it.
Like I said, I think there's room for improvement here, both in terms of interface and in terms of algorithms. But it's far from non-trivial. As for TopoR, it does look like one of the better options, and I really like that it's challenging the 45 degree orthodoxy which is basically a relic from limitations of early PCB CAD which is sadly still solidified in the tools (even in a modern PCB CAD tool it's hard to route something at an arbitrary angle, and it tends to break routing features like push-and-shove), but I haven't had a situation where I've been looking to try it myself (part of this is PCB routing takes up a relatively small portion of my time: if I spent 70% of my time doing it like some specialists I would definitely be spending more time trying to optimise it. As it is it's about 20% of time I spend designing PCBs and I spend less than half my time at work designing PCBs).
I really like the flowing, organic layouts of 60s and 70s PCBs, they are unfortunately very difficult and high maintenance to recreate in modern CAD tools compared to their brutalist brethren. OTOH it's not like anyone will really see the works...
I suspect that to a professional circuit layout engineer having the machine route traces evokes the same feeling as having gethub copilot write your code does to the professional software engineer.
> They mention a host of things that the autorouters are bad at as evidence that autorouters are useless, instead of recognizing the opportunity to improve autorouters to make their jobs easier.
When a bunch of professionals say that something is useless, pehaps you should pay attention?
The problem is that most PCB boards are extremely constrained routing environments. The boards that KiCad is used to design are extremely so. Vias go completely through the board. Even worse, vias tend to be larger than tracks. Consequently, changing a layer is expensive and introduces more obstacles. Your subcircuit part is also an obstacle on your routing layer. And, generally, you only get 2 "routing" layers (top and bottom) since the other two layers are used to route power and ground.
There is a reason why boards that have FPGAs on them tend to use blind vias which don't penetrate the whole board--they can't route to the balls otherwise. They also tend to be 8+ layer boards. This represents real money and if people could do otherwise (either by hand or autorouter), they would.
However, let's back this out to somewhere that "autorouters" are actually useful--VLSI. As someone who has done VLSI design for a very long time, I can pinpoint the moment when VLSI autorouters went from useless to useful--when metal layer counts hit 4+ layers (local connect, horizontal connect, vertical connect, and power layer).
VLSI does not have the same obstacle issues that PCBs have. Vias only go layer to layer unless you design otherwise. Vias also are smaller than tracks. Consequently, you can practically guarantee that you can interconnect things with enough space. Your subcircuit doesn't also interfere with one of your routing layers. And VLSI design has a LOT more money to throw at developing autorouters.
Even so, VLSI autorouting and placement still looks like crap 25 years on. Nobody has yet been able to come up with an autorouter that can identify a datapath and lay things out in a coherent fashion. And there is good money in doing so.
People like you then come along and are suggesting that the KiCad developers spend a lot of time, on a known very hard computational problem, that people failed horribly to solve in the past with a lot more money and will likely only work well on a minority of expensive PCB boards (8+ layers with blind/buried via).
Color me unsurprised when the responses are less than hospitable.
> They mention a host of things that the autorouters are bad at as evidence that autorouters are useless, instead of recognizing the opportunity to improve autorouters to make their jobs easier.
Sounds like a job for DL! No, really, I'm serious.
If you can feed in enough existing layouts, and give the inputs enough information in terms of what signals are differential pairs, what is the intended impedance, what is high-speed, etc. it might be possible to have a system learn how to do this.
I'd think there's enough gerbers and such laying around the Internet from reference designs to have a big enough data set.
Free business idea for anyone who wants to disrupt the EDA market...
There's some psychological effect where people always look for a more professional approach. You see it in software with design patterns and "antipatterns". Autorouting has been declared an antipattern in electronics, because for professional hardware, it isn't useful. However, hobbyists have radically different needs than professionals. There's an entire class of hobbyist electrical engineering - retrocomputer electronics - where an autorouter is essential (old computers used wide but slow busses, so routing 50-100 traces across a pcb is what matters, signal integrity does not).
> There's an entire class of hobbyist electrical engineering - retrocomputer electronics - where an autorouter is essential (old computers used wide but slow busses, so routing 50-100 traces across a pcb is what matters, signal integrity does not).
You can get away with murder at 1MHz if your trace length isn't too bad but you absolutely do need to worry about signal integrity over that speed or large boards.
When I was a beginner starting out with 65C02's my autorouted boards would work fine around 1MHz but it was impossible to get them working at all at 10MHz until I rerouted the board by hand taking care to think about signal integrity, current return path etc.
In my experience, you can get away with a lot up to 10-25MHz. Mostly just proper board stackup (the bare minimum ensurance that all signal traces are on a layer that's next to a solid ground plane layer, with no slots or cutouts under the traces).
Things like trace length, reflections, power dips when the bus is all 1's, electro and/or magnetic crosstalk, etc. become an issue at around 50MHz, although I've never gone that high in a hobbyist design...
Kicad dev here, the autorouter was never part of KiCad. It was a third party tool that had to be separately installed, KiCad's only integration was a button. (There is one GPL-violating fork of that autorouter that has a kicad plugin that adds that button back)
The real problem is that third party tool went abandoned for years due to a major CAD company claimed copyright ownership due to the author's former employment with them (the traditional ownership of IP in employment).
That former author of the router, even though he disputed the timeline of the code's creation being outside employment, basically said "I'm in retirement on a fixed income, fuck this I ain't dealing with it" and abandoned the router. Then over the last 8 years there were random forks that quickly petered out because well, it's all very very niche software.
The KiCad project isn't touching that code due to (a) it being in Java when everyone is a C/C++ domain expert (b) the legal claims by that big company basically make that specific codebase poison so we need to stay away from it.
As for creating a new autorouter, it has come up multiple times. The problem is, anyone can create a autorouter but a good one is a whole different ballgame The best way to describe the problem is while the PCB layout is 2D. Routing is actually a multi-dimensional problem requiring input of all kinds of parameters to do it good. It's just we are a small group of electrical engineering oriented guys and we just don't have the interest in spending our limited free time on it.
We are totally open to somebody contributing it, but alas, everyone expects us, the active contributors to do it instead. You know, that horrible pitfall of open source.
I use Mihosoft Freerouting autorouter with KiCAD. It's free opensource which works reasonably well without any artifical limitations.
Although i prefer to route critical stuff by hand (high current, high frequency, differential pairs, etc...) and let the autorouter to do the rest.
But it's written in Java, which is not really my personal preference. Also there was some performance issue when board outline contained arcs, so i had to convert them to series of short lines which reclaimed the autorouting speed.
Mihosoft/freerouting is a fork of a GPL violating fork (freerouting/freerouting) of the original autorouter written by Alfons Wirtz. (It's GPL violating because these forks proceeded to completely strip Alfon's name and copyright blocks out of all the source files like true assholes). The freerouting/freerouting project on github is still maintained at least.
KiCad's "autorouter" was simply some button integration for use with Alfon's autorouter distribution back in the day. There's a plugin located in the freerouting/freerouting project that adds that button back to KiCad 6.
A comment from the reddit link which makes their alternate seem appropriate (I haven't used kiCad since around 2010, so have no opinion either way):
> What KiCad does have is "push and shove" routing, which is really nice. As you're trying to manually route a new trace, it will push existing traces out of the way as you incrementally route the new one. This is a huge time saver as you manually route your board.
Why is this an either/or scenario? Anyone who has the option (including myself on EaglePCB back in the mists of time) seems to prefer manually setting copper pours, running the "important" signals (whatever that means in the context) etc. and then letting the autorouter do the trivial, fiddly, numerous traces for them. It's not a fire-and-forget automatic PCB layout generator, more like cruise control. Nobody says "the handling on my new car is great, I'd take it over cruise control any day."
Now that I think of it, if I could just get a traditional manual clutch shoved in between my car's automatic transmission and the driveshaft, that would basically solve all my issues with it. Autos are fine these days for all but the most 'spirited' driving, but it still gripes me to not be able to precisely control that front/rear torque split coming into the corner.
As much as I'm philosophically uncomfortable building software for ill-defined problems like time stretching, audio source separation, and image recognition, I wonder if AI can be used to produce a autorouter with better performance. I've seen some companies already working on that.
As someone who scoffs at "AI" and a professional EE who detests autorouters (they take more time to set up than it takes to do the job), I honestly think this is the future. They're a good match for each other, since routing has clear success and failure conditions, a lot of leeway to achieve them (actually too much; this is what usually sinks autorouters, with them painting themselves into dumb corners), no expectation of or need for perfection, and the default presence of a human in the loop (to add the logos if nothing else).
But the real payoff will be in automatic component placement, since that's 85% of the work anyway. And I think the same trends apply there too, it will just take longer.
> But the real payoff will be in automatic component placement, since that's 85% of the work anyway.
I wonder how much separable the problems of placement and routing are. That said, I'd love to see a function in KiCad that does auto-placement (more than I want auto-routing).
In terms of fully optimising the final result, they aren't separable. If you want routing to be likely to succeed, you need to give extra space between components, but this will waste some of it. Getting a good result means the placer needs to have at least some knowledge of the routing. This tradeoff also exists with manual placement and routing to some extent, especially since the tooling it still not very good at push-and-shove for a whole component, especially one with many pins. Also in practice in the design process there's quite often no requirement for an optimal result in terms of space used: before the PCB is designed there's a negotiation with the mechanical design as to how much space is allocated and so long as you're under that you're OK, and there's little bonus points for coming under (since it would require reworking the mechanical design to take advantage of it).
My understanding is that it sounds great but the one magical part about the EE domain is we have an absurd selection of ICs being made every day by companies that are tailor made for every application under the sun. It's the best way to cut physical hardware costs down by every penny possible for volume manufacturing and it's trivial for a human to design schematics and board layouts tailored to the chip in the grand scheme of things.
The problem then becomes that the AI would need to be constantly trained on newer and newer human designed samples for each new chip to keep up.
P.S. If there is interest I will look to document my workflow.
[1] https://github.com/devbisme/skidl
[2] https://github.com/freerouting/freerouting