I would take a PC motherboard, with BGAs, high speed memory and several smps as an example of a board that really needs and uses the capabilities of the high end ECAD packages (at a high price)
I consider a net “high speed” when the signal edge rate is fast enough and the trace long enough that that transmission line effects must by accounted for. e.g. a net that requires a controlled impedance trace along with possible source and end termination.
If I am turning on an LED or static IO, an “ugly” trace route doesn’t really matter too much. However, I deal with boards in with fine pitch (0.5mm) BGAs, high speed (300MHz to 3GHz) signals and high voltage (4kV). On these there are so many complex constraint corner conditions, it’s hard to see it auto-routed without spending as much time entering the constraints as it would to layout.
Way back when starting with Kicad I stated:
We have now great 3D support, much improved differential routing, and just got area-based DRC support. The KiCad (and add-on) Devs have come a long way.
My next wish:
- IPC-2581 output
- Guided Bus Routing support (like Altium)
But CircuitMaker is only for Windows. It’s so sad.
Autorouter, lets see: Altium Desinger-yes, Altium Circuitmaker-yes, AutoDesk Eagle-yes, Advanced Circuits PCB Artist-yes, NI Ultiboard (Ultiroute)-yes, easyEDA-yes, dipTrace-yes, Solidworks PCB-yes…
All of these offerings believe that there is some utility in autorouting and I agree.
Yes/no is too simplistic. You would need to take simple, medium and complex designs to evaluate each, then gripe about the results
I would never autoroute any signal over 10khz. And today only very complex designs use Addr/Data busses. Serial busses are fast and only a few lines.
KiCad is not stopping you from using any autorouter you want. Elektra/Konekt, Pulsonix, TopoR, gEDA and Freerouting are all supported.
Whilst there are good outside alternatives, high quality aspirations, limited developer time and other significant priorities, this is not going to happen. All software needs development and support and there just aren’t sufficient resources available to the KiCad team or motivation to add autorouting at this stage.
Read the whole thread for more details. And this Autorouting, autorouter, autoplacing
Are you speaking for the development team?
Nope, but John’s post is pretty much in line with what the Kicad team thinks I can’t speak for the rest of the devs, but I’d rather not spend years of my life developing a high quality autorouter just because some proprietary tools do have an autorouter (whether their autorouting results are acceptable is a different story…). P&S is a sufficiently large beast to maintain.
T.
Is clean-sheet development the only alternative? What about integration of one or more of the freely available autorouters? I have used freerouter.jar and it works, but it is a pain to do all of the steps to make it work with KiCad. And I haven’t figured out a reasonable approach to autorouting when the signal plane has a copper ground fill (zone). And not just everyone has the API expertise to provide reasonable integration of existing tools.
But your response, “…I’d rather not…” suggests that it is more about your personal development efforts than what is good for your KiCad clients; unless I misread–then I apologize in advance.
And for those that don’t “like” autorouters, its mere existence doesn’t make it a requirement to be used.
Open source software development is a bit like stone soup. Most people can bring a pebble, but it’s difficult to find someone who can bring a big rock unless there’s an interested and capable person and sponsorship to pay the bills. Unfortunately autorouting is not something that can be broken up into smaller chunks for many to solve.
Don’t forget, Kicad is largely voluntary so Developers choose what appeals to them to do.
The code is open source, contributions welcome.
Otherwise, there are developers who operate an independent company who offer paid development and support services for KiCad if you want to pony up the cash for them to spend their time developing the autorouter.
The rest of us work in KiCad in our personal free time as a hobby and enthusiasts. I can tell you my professional wage is easily $100/hr otherwise
Written in Java for a start and with history of patent or trade secret problems, which is why the original developer published it and walked.
That is $150/hr
That is $150/hr
And anything that touches topology (for those who don’t know, it’s a branch of mathematics that thinks a coffee mug and a donut are the same, yet, for some reasons its theorems are quite useful when put to work in PCB routing software), it’s $250/hr (studying topology is known to cause heavy brain damage).
T.
So I’m an embarrassingly poor guy. My wage is $20/h for studying retirement .
Donations welcome
So I’m an embarrassingly poor guy. $20/h for studying retirement .
$250/hr is a price for the people who thinks they are “clients”, like @jonhp who seems to consider himself a “client” because he downloaded KiCad (although I doubt he would’ve ever chipped in for the development). As many people already remarked here, most of KiCad devs work for free (myself included) and we are happy to fix bugs, add new features and generally improve KiCad - but some users seem to expect us to do exactly what they desire, disregarding our personal goals. This is not how open source software works, at least not community-driven open source.
Back to the autorouter - this is not something that can be coded in spare time for free to have satisfactory results. We don’t want to have a poor quality autorouter making a big mess of wires just because some other tools have one. Not to mention that - at least to me - investing my personal time for autorouter development is not really a goal I would like to pursue, I design PCBs (sometimes quite complex) for my living and quite frankly, never needed to autoroute anything. There are cooler things to work on, like improving the push&shove or guided routing which IMHO are much more useful and also bring fun and fulfilment to the devs.
Tom
PS. If somebody wants to contribute a quality autorouter to KiCad - our doors are always open, but please, write it in C++ (GPL or LGPL), without a ton of external dependencies and without patent/copyright issues or generally ‘shady’ legal status (like Freerouting).
PS2: Since we started talking about prices, here’s an example price list:
Hillarious price list
There are cooler things to work on, like improving the push&shove or guided routing which IMHO are much more useful and also bring fun and fulfilment to the devs.
…and pad stacks, and a decent symbol/footprint/library management, and a property inspector, and tracks & zones in footprints, and … (fill in the blank).
I totally agree with what you say. Not that that would effect anything, but anyways…
@twl first I need to apologize for the use of the word “client”. I use it interchangeably with “user”. I will, in the future only use the term “user” when referring to KiCad. And your assumptions are incorrect. I have contributed (USD) to the KiCad develop several times; although not lately I am embarrassed to admit (I will correct that ASAP).
But I am confused about your view of “user” input. In your view, is it of no value?
Is an autorouter not a “…new feature…”?
There are current “features” that I have no use of; but I haven’t asked that they be removed or abandon. Since you don’t need an autorouter, then by your argument we should all fall inline even though some of us have such a need.
This discussion seems to confuse what the developers personally want to work on and what features are wanted by some subset of users. But I am getting a better sense about the ultimate future of KiCad.
And one more thing about this dialog. I thought it was a technical discussion about autorouters but it has unfortunately devolved. I feel badly about that.
Jon
PS I would also remind everyone that not all “users” are code developers!