Why do people choose to NOT use the auto-router?

IF the placement is logical and the re-pinning of multi-chip parts (or GPIO) and the design is fully constrained (v6 type constraints) then why not use auto-route. By the time you have that information the design is fully constrained that it a computer can do the work

The problem is a lot of this information cannot be generated the moment you start the PCB part of a design and almost always it is an organic process as issues arise and parts are moved/rotated/re-pinned. In this case manual will almost always produce the better result.

For relatively simple cards a PCB engineer I use to work with would place the parts based upon my guidance (higher level considerations) and just it auto-route and then spend the next few hours jogging the design to satisfy his OCD or other considerations

I have only experience with 2 layer boards, and really only with SMD elements (I designed PCBs with TH elements so long ago that I had to design it using checkered card and pencil. Proper element placement is the biggest part of PCB design. Making traces as short as possible is the first step on the road. Placing resistors together and capacitors together is in my opinion absolutely senseless. I always try to be sure that I know which way each connection will go during routing.
With PCBs I route (one microcontroller + several elements around it) my strategy is:

  • all bottom to be used for GND. No other tracks there. In most PCBs I reach that goal. Sometimes I allow myself for one ot two very short signal tracks at bottom,
  • so I can hide GND connection lines during placement as I have GND everywhere one via from me. With KiCad 5.1.x to hide GND I delete it (text editor) from netlist (100% deletion) or place GND zone at top (close to 100% deletion - you have to press ā€˜bā€™ many times). With KiCad 6ā€¦ as I have read it will be possible with no tricks,
  • define power supply that way thet I get VCC made near one microcontroller corner,
  • go with VCC under microcontroller (under but on top layer) and go out through all three rest corners and through its VCC pins (I use uC that have VCC at each side), that helps to reach with VCC elements around uC with no blocking (too much) other connections to uC pins. If you go with VCC around uC to connect it to all its VCC pins than you canā€™t connect anything to uC without jumping to bottom PCB side.
  • as uC pins can be flexible used for many tasks at that stage I select right pin for each task to untangle the connections as much as possible,
  • when I finish placement I in most cases know which way each track will go (I sometimes route some connections partially only to get the connection line out of the region I am interested to not disturb me in imagining which way the connections I am thinking about I plan to route.

But my PCBs are rather simple. I suppose that when someone has for example BGA (or many BGAs) it is not possible to imagine all connections during placement. But as he have not only 2 layers he has bigger possibilities.

There are many, many other considerations and sometimes the goals contradict each other.
The links I have given some time ago explain (among others) why I use all bottom for GND:


Few posts later in that thread I gave more links.
After reading all that you will understand most PCB design problems I think.

As I understand you are a programic/informatic man (if I were better in English I would probably wrote it differently) I associated it with one problem we had recently with software developers (in other firm).
I write it just because it is (in my opinion) a good example of how the software and hardware worlds differ. They just did something we had never expected anyone can be so thoughtless to do it that way. Imagine an array of 32000 data records (cards in access control system) stored in flash memory. Our program assumes that record filled with FFs or 00s not contains valid card so is skipped when searching for card. So if you need to delete one record you just program it to 00-s - one programming operation for one page (page need not to be erased first).
But someone there decided that in such situation (someone fired or lost his card) it will look better to not have empty records so we got a serie of orders to write 0s into n+1 record (erase it) and then program the right data into n record. To protect flash our program checks if it is possible to write data without erasing the page but as that record was just programmed to 0s it was never possible so each write needed to erase page first. He went through all array even only 5 records were not FFs. You can assume flash runs out by number of erase operations. So instead of 0 erase operations we got 32000 page erase operations. He should left that 00-ed record between others, but even not he could use the order ā€˜write FFs into records from 6 till 32000ā€™ - it would not run out flash so much. By this solution he shortened the expected device live many times.

Maybe a bit offtopic, but I found one phrase in a paper by Texas Instruments kind of funny, considering that EE is very technical area of expertise. It said ā€œas close as humanly possibleā€. Maybe that rules out using an autorouter :slight_smile:

3 Likes

If the design wouldnā€™t work with 25cm clock line, then the constraints were not set up properly. Sure, a manual layout would have likely resulted in shorter traces which would have been more likely to work, but if there are specific restrictions, they should be in constraints.

It was not my design. I have never tried this autorouter. I donā€™t know if there were possibility to specify such restrictions. I even donā€™t remember what that device was expected to do.
What Iā€™m sure is that after cutting out that long trace and replacing with wire it started to work.
Iā€™m also not sure if it was signal and its clock. After rethinking I suppose that it was design with racing - probably just assuming that you can use slope to latch-in some state which is then changed by the same slope propagating through one gate.

The reason I donā€™t use the auto-router is because I donā€™t know how. In fact, I didnā€™t even know kicad had an auto-router until I read this thread. If somebody makes an instructional video, I will watch it and see if it is worth my time, or not.

Clock lines and other edge triggered control lines are always fussy about length. When they are too long you get reflections causing ringing on the edges and double clocking.
You start by placing components with clocked data near each other first and then the decoupling capacitors

Board layout is an artform. Autorouters are not artists.
If it were simply a ā€˜join the dotsā€™ exercise then autorouting makes sense. But its not. Designing a PCB properly requires a deep understanding of how the circuit functions, and the implications of each routing decision. There are often considerations beyond basic circuit function (EMC comes to mind in particular) that can be quite difficult to distill into a rule set that an autorouter can follow. And inevitably there are compromises to be made. How do you code a compromise?
In the end a (qualified) human will do a better job than an algorithm.

2 Likes

May be you need not to do it. The artificial intelligence will do it instead of you. Some time in future. Probably faster than we expect :slight_smile:

2 Likes

KiCad does not have a build in auto router. It had a primitive one in the past with the legacy canvas but there never has been one in the modern toolset.

The only ā€œgoodā€ option is an external java tool (freerouting) with questionable legal history that is no longer maintained by its original author.

1 Like

I desperately need to add this as off-topic: If something is a Java tool, my spider instincts always warn me to step back :slight_smile:

The main problem here is that many people view connections in a schematic, and also wires or other conductors in the real world, as ideal connections, but they are not. They are components that you shape as you do the design. They have inductance, capacitance and resistance, i.e. complex impedance.

If your circuit is slow (including edge transitions), and the currents are small, the effect of wires is small. If you can neglect small effects, then you are ok.

But, if you have fast transitions or other high frequency stuff, the impedance of the wires can be substantial, and you have to think about them if you want a robust design.

Or, if you care about high analog resolution, i.e. instrumentation or audio, then even small impedances can cause quite a few LSBs of error, so again you have to think about wires as components.

I have not used an autorouter, but I would hope that a good one can account for some of this stuff. But, if you are applying routing constraints, knowing what constraints to apply means thinking about wires and connections as components. But, for RF, analog, or power converter design, every design I have ever seen (which is many) is routed by hand. I donā€™t do much digital.

John

In addition, autoroute require massive of constraints setting up. And you going to get to the points where your constraints are impossible to meet all. Event ML would not going to cut.

Iā€™m wish I could have spare time to play around with KiCad code base for ā€œauto-routeā€ aid / interactive help instead of reach for fully auto. It never going to end well.

OFF-TOPIC
Kicadā€™s architecture specifies that every file it creates is a text file, and that every file it writes is a text file. I understand this makes it very easy to create an external [to KiCad] program that does one specific task on one of Kicadā€™s text files for a project.
IMHO, this is a superb architecture.

Is it easy to tell by looking at the Java script which text file it reads and which text file it writes to, or is this association with a particular file hidden by a level of abstraction in the running Java script ?
( I program in C and C++, but not in Java. )
In other words, does the Java script incorporate into it knowledge of Kicadā€™s files for any one project ? (Maybe I am asking this question because I am ignorant about how Java works.)

freerouter does not work specifically on kicad files. It works on the dsn file which is one of the formats that kicad can export to. And the result can then be imported back into kicad via the same interface. DSN was originally used (specified/invented) by specctra.

PCB layout is the physical realisation or your abstract proposed solution - i.e. your schematics.
Your PCB is not just the thing that holds your electronics together. It is a part of your design. It is made of conductors and other materials that electromagnetic energy interacts with. The tracks have resistance, inductance, capacitance. They carry current, sometimes get warm or hot. They cause voltage drops. They can radiate EM energy and are also susceptible to pick it up. They can distort your signals. The vias have inductance.
We can though use some of these effect to our advantage depending on our design. PCB antennas, filters, delay lines, PCB heating elements, RF couplers, impedance transformers, power combinersā€¦
Depending on the materials used, some of these will vary with temperature and moisture.
Depending on what you are doing, sometimes the effects are small and have little impact on your design, sometimes they are significant and critical.
You would not usually design a circuit without reading component datasheets and nor would you usually layout your circuit without understanding what is happening to the voltage, current and EM energy flowing around your board.

@Russ,

Java != Javascript. Even though the names are very close, they are two different, I donā€™t know, ugly beasts? :slight_smile:

Java is a Just In Time (JIT) compiler which is compiled into bytecode and then reinterpreted in the target platform. This is designed to be as much portable as possible. But the result is quite the contrary. You will have problems even between the minor revisions, not major. So youā€™ll end up with many revisions targeting different java versions. And Iā€™m yet to see a robust Java software. Every Java software Iā€™ve used had stability issues and donā€™t get me wrong some of them are multi-million projects.

Javascript on the other hand had been developed to be a script language, providing small interactivity on the browser front end. But then things had become a little bit different and interactivity moved from server side to client side. Javascript became a requested language and this wave created another hideous platforms like ā€œelectronā€, which is a massive resource black hole. You know we had WinAmp in the past in our dirty old machines and it was working well with couple of mega bytes. But then we have spotify, eats over 1GB memory without a proper reason :slight_smile:

In other words, does the Java script incorporate into it knowledge of Kicadā€™s files for any one project ?

As far as I know it doesnā€™t touch any internals of KiCad. But if you need to develop some interface, you need to know at least the file format to process it.

There is an interesting and very useful project Iā€™d like to mention as an example. @qu1ckā€™s Interactive HTML BOM. Which utilizes Python on KiCad side and Javascript on the browser side. It creates files from KiCad side with Python and then processes it with Browser and Javascript.

Whoa, whoa, hold your horses. JS is ugly, no argument there but java is the bees knees. It gets a bad rap among non developers who only interact with java desktop apps, which are shit, pretty much universally. But through no fault of java, itā€™s just that is not itā€™s main use case and UI libraries for it suck.
But itā€™s one of the easiest languages when it comes to writing and, more importantly, maintaining in the long term any large software. Itā€™s beautifully structured, easy to read, has fantastic core API, itā€™s runtime is rock solid. There is a good reason Google, Facebook and the like write good chunk of their backend systems in java.

JS is also a good language for what it was designed. Do some client side calculations in a browser sandbox to change the web page dynamically. But then some lazy genius decided it would be a good idea to write server applications in it, probably because (s)he didnā€™t want to learn anything else. And now we have the dumpster fire that is JS ecosystem.

4 Likes

@qu1ck I should have mentioned that Iā€™m a developer, too :slight_smile: This is a very subjective matter and I donā€™t want to derail this topic. So, maybe we can share our experiences in another topic, one day :wink:

The legal side seems to have gone quiet, but Freerouting has a very limited support for more than two layers when there are planes used

2 Likes