Please don’t give him any tools, he might break something
The point is that it takes as much, if not more time, to properly set up an auto router vs manual routing. Those that don’t understand this are the ones most likely to use auto routing.
If you institute an auto router you take on the task of supporting it. That means every instance it doesn’t work. That means an ever growing list of variables to check for, both in software and user end. At this point it is a black hole the developers don’t have the time for. Those that benefit the most are occasional hobby users because many of their boards are 100% ‘doesn’t matter’ in path tracing.
The algorithms are out there in open source software but no one seems to think it worth their while to implement. It’s all choice. 
3 Likes
Ironically, these should be the reasons in favor of using autorouters; there are sooooo many rules to good PCB design, and computer programs can be sooo good at not forgetting and not overlooking any of those.
I know that autorouting is an exceedingly complex problem (computationally speaking; not sure whether it is a known NP-complete problem or something like that) … And I understand that it may be a matter that actual, currently existing autorouters may be extraordinarily bad in terms of the quality of the routing (I do not know one way or the other).
But anyway, this “anti-autorouting” general sentiment reminds me of my days in my first job as an embedded engineer; I was forced to learn C (at the time, the only programming language I knew was assembler — and I had had some contact with PLM-80 at an internship). I remember my approach to learning C was to code something, and then, being unsure whether the code I wrote meant what I thought it meant, I would ask the compiler to produce assembler code, to inspect the assembler and see if the behaviour of the program was what it should be.
I completely and utterly abandoned assembler after I can’t remember how many times of looking at the assembler code produced by the compiler and thinking things like “riiiiiighttt, of course, if I move the lower bytey, then rotate and then use that as the subscript into memory, that is sooooo much more efficient than the way I would do it” … (or whatever; this was just some random nonsensical example: the point being, I learned more clever tricks to good assembler programming during the two or three weeks looking at the assembler output from a C compiler than I had in two years during my undergrad + six months of an internship — and this was late 80s, when compilers were just starting to get good!!!)
I guess my point is that I see a strong parallel (at least in terms of the potential for what autorouters could be) between manual routing being like coding assembler vs. autorouting being like using a high-level language such as C or C++ or you-name-it.
Nowadays, it is extremely rare to find someone (excluding clueless beginners, that is) who thinks they can code better assembler than the output of a minimally-decent modern compiler … But back in the day (maybe early to mid 80s), it was the norm: most computer / embedded engineers were absolutely convinced that coding assembler was the right way, and would see the use of a high-level language like C with a healthy dose of scepticism … (and even after a while, there was still the widespread belief that humans could code better assembler than a compiler, even when it was already accepted that the convenience of a high-level language justified its use)
5 Likes
It is exactly the way my brother was also going. We divided a work between us - he writes for microcontroller, I write for computer. So I started from learning C, and then C++ (I have never known assembler). I have never written even a simple program for microcontroller (neither in assembler nor in C).
I’m curious if C compilers are smart enough to discover that given C code is used to get something that assembly language is simply given by definition.
We use CRC16 code according to one old appnote from Atmel (is fast as skips bit by bit byte rotation).
Copying it from assembler to C (to use at PC) I got:
int crc16(byte* buf,int n,int crc) // crc16: addition bufor n bytes to crc
{ // Polynomial = x^16+x^15+x^2+1
crc&=0xFFFF; // mask of higher bites (if happens to be there)
while(n–)
{
int d=((*(buf++))^crc)&0xFF; // lower crc part
int p=d^(d>>4); p^=p>>2; p^=p>>1; // parity bit at bit 0
crc= (crc>>8) ^ (d<<7) ^ (d<<6) ^ ((p&1) ? 0xC001 : 0);
}
return crc;
}
Will C compiler find that it can skip the line:
int p=d^(d>>4); p^=p>>2; p^=p>>1; // parity bit at bit 0
and just use register parity bit.
We still use some assembler written code for AtXmega 8 bit microprocessor. My brother says (and I believe him) that it is not possible to write in C SHA256 that way to get after compilation for ATXmega as fast code as his code. He had to use really all registers to count it without using RAM, and C compiler (as I believe) restricts some registers for something and can’t use it inside such procedure.
1 Like
Awesome follow-up Piotr!! Enjoying the discussion, even though we are by now soooo off-topic :‒)
And yea, I have to admit that you’re poking holes in my argument; perhaps modern microcontrollers have advanced in things related to bit manipulation, and maybe compilers are not that good at those as they are in general??
Incidentally, I’m remembering that in recent years I found myself coming up with an 8-bit AVR assembler version of a FIR calculation that ended up being substantially faster than the C counterpart (if you want to get even further off-topic and are curious, this is the work where I tried that). This could have to do with the AVR gcc compiler not being too good? (I’m not sure how big is the community and the effort spend behind that product)
There’s the flip side of the argument: while attempting an assembler solution for a CAN-bus related task, where very precise timing was important (that was the main reason why I attempted assembler), I ended up having a flashback to my days of learning C: I discovered a neat construct/trick in AVR-8 assembler thanks to looking at the output from the compiler!
But all in all, it may seem like, while being very vocal against assembler and so emphatically proposing that C compilers do a much better job than a human, it would seem like there’s still that instinct in the back of my mind, that temptation to try assembler, that “who knows, maybe this time I will do better than the compiler?” playing in my mind :‒)
The challenge is inputting this information to the autorouter. The auto router has to be told which are the critical tracks, which must be kept as a pair and length matched etc. Some of the common autorouters lack the control to do this. The good autorouters that can do this well are expensive.
1 Like
Fair point, of course. I guess my view goes more with the potential for what autorouters could do in the (near?) future. Techniques and ideas on how to do autorouting and how to efficiently collect important information from the user could (should?) dramatically improve over time. Similarly for how to integrate other technologies such as EM-simulation-in-the-workflow, AI / deep learning type of approaches, etc.
1 Like
im sure it will get there at some point but right now the two ends of the spectrum are
- Someone new to PCB layout uses auto-routing and get a shocking design
- Someone with experience spends soo much time fully constraining the (top of the line) algorithm that they would have had it placed and layed out in a fraction of the time
This gulf has to shrink considerably for it to be taken seriously
2 Likes
There is also the following problem. Good autorouter is a very complex piece of software that needs large teams working on it and large investments. It only makes financial sense to develop it with large electronics companies as target clientele. I dont see it trickling down to EE hobbyist or small fish firms because they frankly don’t have the kind of projects that benefit from autorouters. And amateurs wouldn’t even use that autorouter if given for free because they don’t want an autorouter, they want a magic stick.
4 Likes
In fact, this involves two issues:
- Auxiliary routing
- Automatic routing
For auxiliary routing , it does not need to consider rules, just simply avoid obstacles and connect a few endpoints.
However, automatic routing involves many necessary rules. In a simple PCB, the cost of pre-preparation will be far greater than using manual routing.
So I think everyone may not discuss the same thing here.
I think that regarding to parity bit calculation the C language is to blame, not the compiler. If in C there were parity bit operator it would be obvious to use it and compiler would certainly know how to translate it into assembler.
In our RS485 bus (up to 50 devices) anyone can start transmitting when it needs. Microprocessor UARTs don’t give you information that at that moment no one other just started to transmit so in parallel to UART the other part of interrupted driven code is looking at RXD line.
I can imagine, even I have never written a code in assembler (even the book I mentioned here:
was full of assembler examples).
I have only written (around 1990) an assembler itself and for 8051 my brother was using only my assembler. I used 32 bit numbers for internal calculations and my brother used it to calculate RS232 speed based on quartz frequency. He got overflow in that in other assembler he could use (they used 16 bit numbers).
I have never used auto router but when I think how to tell it what is needed I always think of VCC lines that I want to be wider than the standard, but only where the current flows. VCC does not need to be 40 mils path to 47k resistor suspending any input. I think that defining how to describe it will be complicated and even if it will be done then time spend on entering what have to be connected with 40 mils and what can, but need not, and that even microprocessor VCC pins I want to be routed by 40 mils but the connection itself may already be like its pads, and if entering with 40 mils track under TQFP is not possible then narrowing down to 30 mils is acceptable (but only for a short distance).
I think that in time needed to formally write all these restrictions I will just route it myself. Specially that thanks to KiCad Interactive router is really good it takes me only about 10% of time spend on PCB design.
1 Like
Until someone will construct perfect AI which will be able to learn the same way as designers learn and no more software will be needed to write. AI "will watch’ some thousand of perfectly designed PCBs, will ask some questions to their designers and ‘done’ - it will know how to do it 
The AI would have to understand the circuit. I think at that point you have just reached the Singularity and the human race become obsolete
1 Like
I drop out assembler when I realised the C compiler made better code than me.
I drop out the autorouter even sooner, when I verified that I made better routing than the autorouter.
I must say that maybe I would never have started my first board without an autorouter. It was OrCad those days. The routing was auful but il let me know it was “doable”.
1 Like
I admit that there are circuits that are very critical in some regions, like RF designs, DC/DC etc. but even then you can place key parts properly, maybe lock some tracks, then autorouter has almost no other way than placing remaining tracks also properly, or at least quite descent. I’ve just finished one board using auto router, one sided board, 95% of tracks were made automatically. I had to correct some DRC errors only and change placement over and over, remap some pins on MCU, look through power tracks if they don’t go around the board etc., but even then it would cause zero problems in my case. The worst problem was to fix issues with power supply tracks, Vcc, GND crossing itself all over the board , supply for analog and digital part of MCU, that would be totally no problem on two sided board, but that one is one sided, I wanted to have it done no time at home Time to design that board was like 1-2 working day. But what do I know, I’ve only made a few PCBs successfully 100% this way
I think this forum is mainly for hobbyists, and those using professional software are using an auto router anyway, they only don’t talk about it. The difference is that it works much better than in free software.
1 Like
So you didn’t use it but you already know it’s so bad ? Intresting. In case you have mentioned auto route tracks with Free routing or Topor normally and then edit tracks width, simple as that. Or get Altium and set many options there are, to make it work , but then you don’t need Kicad. You might be right, preparing rules in Altium might be time consuming for simple boards, but for bigger it pays of for sure. In Frerouting and Topor there are not that many options.
1 Like
I’m probably in a similar situation as Piotr. I tried an autorouter a few times some 30 odd years ago, and cleaning up the mess was more work then laying out the PCB manually in the first place. So you form a first opinion, based on your own experience, and it feels like you’ve wasted a day or two of your time.
Then, over the years you hear and read lots of comments of people with similar opinions.
Doing it manually also has the advantage that you see all connections once again, and I’ve caught errors in the schematic several times in this way.
But I do not make many PCB’s, and the PCB’s I do make are relatively simple, so there is no need to spend much time on learning an autorouter. If a (somewhat decent) autorouter was integrated in KiCad, I would give it a try, but it’s not high on my priority list.
I also know there are people who make big & complex PCB’s and who are pretty much dependent on an Autorouter doing it’s job properly. For the last 10 years or so the trend seems to be to go somewhere in between. A way of “guided routing” where an engineer uses his experience to give global paths of where to lay tracks, and the autorouter filling in the details.
Below is a PCB I’ve designed some time ago, but never manufactured. It is a simple (50mm*50mm) STM32F103C8T6 development board with maybe a strange set of rules.
- It’s only 2 layer.
- It’s pretty dense. Footprints on both top & bottom. Big 1206 resistors because I have plenty of them.
- Still a quite decent (although stitched together) GND plane.
- “Star GND” for the decoupling caps of the STM32, because of it’s ADC. (I could not separate the analog part further.)
- Optimized layout for the TPS54331, according to its application note.
- Ridiculous big old fashioned crystal. I may change that…
- Made for hand-soldering, so I don’t care about via’s in pads.
- Spark gaps, TVS & PPTC’s for reliability (24Vdc on RS485…)
- Different connector options. RJ45 or big Phoenix pitch 5.08mm for the Power & Data.
- Small experimental area to add for example some kind of sensor.
At the moment it passes DRC. I’m curious how far you’ll get if you delete all tracks from this design and then run it through an autorouter. Are you willing to give this a try?
I recommend to not mess with the footprint placement. All the high stuff is on the front, the back has it’s highest parts (TVS diodes) spaced as widely as plausible to act as “feet”. SMPS is close to TI’s recommended layout, and most importantly, The PCB can (and is) routed properly with this footprint placement.
I had a short peek at the topor website: https://www.eremex.com/products/topor/ and they apparently do not bother to state which operating systems it runs on, so I assume it’s windows only, which means it’s useless for me.
2021-09-04_mumar_base_stm32.zip (171.6 KB)
I design typically few simple boards per year (microcontroller + some inputs and outputs). May be because of it in my opinion auto router is not useful (everyone sees from their own point of view).
1 Like
In a direct response to rich55’s original post:
A lot of excellent answers and reasoning has already been given.
From info I gleaned from this forum and the developers communication on gitlab there are both much more urgent issues, and there simply are not enough developers for KiCad to develop a complete Autorouter. A full autorouter needs quite a lot of sophistication before it becomes really useful, and in the mean time it would absorb lots and lots of development hours without anything to show for it.
The Interactive router on the other hand is already quite good, and it is already implemented in KiCad. It can also be improved in many ways and in small steps, and that is considered a better use of development hours for KiCad.