INTRODUCTION
Most PCB design software packages have autorouters, but professional PCB designers don’t use them. They can have some usefulness to save time if configured properly, but should not be expected to be able to do the work of PCB design, especially when signal integrity is crucial.
I started using what was called Protel back in the early 1990’s. It had an autorouter, but was also designed specifically for manual routing, and the user interface for manual work has actually been their advantage all these years. Early on I assumed to use the auto-router, then manually clean up the layout afterwards. 100% completion by the auto-router wasn’t something that could be expected without at least some user intervention. While performing such clean-up the flaws of the auto-router would become apparent.
As designs became more complex and the time spent compensating for the weaknesses of the autorouter far exceeded the amount of time and effort to configure and run it, eventually there ceased to be any value in using it at all. This might normally take the experience of finding signal integrity problems in the assembled circuit board, requiring those boards to be scrapped and the layout revised.
Small start-up businesses sometimes could not afford that time and cost. Not to say most problems could be chalked up to the autorouter, but if someone is just using an autorouter they will probably have much bigger problems with their product resulting from the general lack of experience.
At the time, I was working on power supply designs and the thing about power supply designs is that they require loop analysis, but PCB layout software in general, including autorouters, are net-based or nodal. This means that in a net with more than two nodes there is no distinction between a connection between any node and any other node. For example, if you have a powerful voltage converter and you want to have a small LED to indicate that it’s on, well as far as the software is concerned that LED requires as much current as the power supply can output just because it’s on the same net.
Maybe I’m just prejudiced against autorouters and after all these years this technology has improved and grown passed me? Well, no. For more than a decade I was doing DFM (Design for Manufacturing) reviews of PCB’s for many clients and I can tell at a glance if a board was routed automatically. It’s surprisingly common especially with small start-ups trying to save money on staff and software.
There isn’t any reason to expect an autorouter to improve, no matter how much time goes by, simply because good designers don’t use them. In order for an autorouter to make good signal integrity decisions it would need to be programmed with thorough and specific rules for each PCB layout and some of the details may not be apparent. Given the amount of time it takes to do an individual PCB layout and that it’s usually a one-time job, it doesn’t make any sense to try to spend that time making a perfect set of rules when the autorouter is still not going to do a good job.
ADVANTAGES OF AUTOROUTERS
The only hypothetical advantage of autorouters is that they save you the time and effort of manually routing. After placing all the components, you hit the autoroute button and go on break. When you come back the work is done, or not. I do not find even on what should be easy layouts that the autorouter completes 100% without any intervention, but 95% or more could be done automatically in a fraction of your time, while you are free to do something else.
DISADVANTAGES OF AUTOROUTERS
Perfect Setup Requirement
What the autorouter does is dependent on setup and rules as well as component placement. It becomes your job to make everything perfect before handing the job to the autorouter. If you do not setup the rules correctly, the routing will not be acceptable. This requires planning in advance which is true if you do the routing manually, except that while routing manually it would occur to you if there is anything wrong before too much damage is done.
Autorouters will not realize that you could move a component very slightly or rotate it to make routing easier. The autorouter will just get stuck on unrouteable contentions. It won’t be apparent where contentions really are because of the autorouter will meander far away from a constraint in search of an alternative path rather than drop vias immediately where they can cause further constraints. One defining characteristic of an autorouted board is a lack of concentrations of vias. Autorouters tend to distribute vias evenly across the board.
Unnecessary Meandering
Autorouters inevitably take meandering paths to avoid contentions. There are cases where meander is necessary for length matching, but I would definitely not trust any autorouter with any signals that had signal integrity requirements. The longer the meander the more vias a net is likely to contain as it crosses over more stuff the farther away it goes. Unnecessary meanders are the easiest way to spot a board which has been autorouted as their antena-like appearance stick out like a sore thumb. A trace goes a long way, sometimes a very long way, like halfway across the board or more, does a U-turn around a via, then comes all the way back. Or perhaps instead of making a U-turn around a via, it makes a short via trip of its own to jump over the track that it travelled half way across the board to go around before giving up. So this little jump could have been much closer to where it actually connects. I’ve seen these so many times because they are common in autorouted boards and so easy to spot as well as correct. It’s just an inherent flaw of autorouters.
There is a hugging pass to shorten paths, which is very slow and not used in any of the default strategies, but do not expect it to move let alone remove vias. The gloss command is essentially the same as hugging, although I’m sure is a completely different algorithm, does not move or remove vias, nor does it move paths over pads or vias, it only pulls the paths closer to shorten them, and therefore it would not satisfy my expectation of shortening meanders. So there is often a shorter path possible that these algorithms will never take.
Lost Opportunities
The larger and more complex a design is, the longer it takes, and the more time you have as a designer to develop insights and catch potential problems. Small, simple designs are more prone to obvious, “stupid” little mistakes because you didn’t have to spend hardly any time looking at it to get a chance to notice those little things. Since autorouters take away that time, the potential for both little and big mistakes on large designs piles up. Large organizations would compensate by having teams of people review designs, which is tedious and still leaves room for error, but what if you don’t have a large team?
Loops, Zigzags, and Tangles
Autorouters sometimes or often make a tangle of routing in contentious spaces. These appear as loops or zigzags, which it is not able to remove on its own and prevent completion. Since these usually interfere with completion even amateurs try to clean them up otherwise they won’t get to the finish line. It’s the inability of the software to recognize and remove these obvious problems after decades that surprises me.
Clean Slate Protocol
The worst disadvantage of autorouters and the reason why I and most professionals won’t use them is that it sometimes takes longer to clean up the mess than to route manually. If you think about any job, would you rather start from scratch, a clean slate, or start with a mess that someone or something made before you, that you have to clean up first before doing the actual job?
VIA OVER-OPTIMIZATION
The way autorouters implement vias is a bit counterintuitive. Autorouters were originally written decades ago during the reign of through hole technology. In those days there was a drilled hole for each node, so vias were considered superfluous and autorouters had (have) an extreme prejudice against them. With SMT parts, especially tiny parts there is no other way around them besides using vias, so this prejudice against vias is trouble.
To make a comparison, there are 1199 pads on my reference board and the autorouter used 262 vias, so if it were through-hole that would be 1461 drilled holes. On my version of the layout I used 321 vias, about 60 more vias than the autorouter, and there are some through hole pads, but the total number of drilled holes is only 406. There are over a thousand fewer drilled holes than a hypothetical through hole version in either case, so the difference between the number of vias in the two layouts is really negligible. There’s no question that my version of the layout is superior since all I did was make improvements to the autorouted layout which was not even 100% complete.
The autorouter doesn’t seem to have any passes or tactics for reducing via count. The autorouter defaults to avoid using vias, this comes at the expense of meandering, excessively long sometimes weaving paths, but it gradually resorts to using vias, increasingly aggressively, towards its goal of completion. This results in a few nets having excessive numbers of vias while most have none. I didn’t just add a bunch of vias, but I did change several long and twisty paths to shorter paths by using vias, something I wouldn’t expect the autorouter to ever do. And by doing this it made several other meandering paths much shorter, reducing the excessive number of vias in some cases. While routing manually I would avoid using vias in the first place, so I find it more frustrating to have to deal with nets that already contain a lot of vias.
I also added some stitching grounding vias to ensure polygon coverage of the signal layers, something that autorouters can’t be expected to do.
Via tolerance is an absolute setting for the board as a whole. The autorouter has no regard for the nature of the signal carried by any individual net. You can’t use any rules to designate any nets to be more or less tolerant of vias because no such rules are available. This would be a necessary step in any improvement to autorouting, especially using third party tools. There is a maximum via count rule, but I don’t think the autorouter cares at all about this. The rule specifies an exact number, rather than a qualification of how favourable they should be the way it is in the strategy setup. I don’t use such a rule because I am conscious of vias I place myself and all this will do is require me to waive the rule from time to time, something the autorouter cannot do.
The default setting for via tolerance is actually relatively high and I didn’t even bother testing any lower setting. There is a Via Miser strategy, but you can’t see the actual via tolerance of any of the default strategies. It seems to me that maximum via tolerance is the only way to go, which isn’t even that much higher than the default, since while you will end up removing a few, you are more likely to add more.
TESTING THE AUTOROUTER
It had been on my mind to test the autorouter for some time, but what I really needed was a PCB layout to work on with some specific characteristics. I don’t have time to make up a random board just for testing.
Since I’ve been doing PCB design for so long and I never use the autorouter, my workflow is structured as if autorouters didn’t exist, so for me to even consider using it I have to change my normal workflow. So I needed a board layout that wouldn’t suffer as a result of a drastic change to my workflow.
If you are going to use the autorouter you would do all placement first and only manually route absolutely critical connections. My habit has actually been to place components in groups or blocks and route them and then arrange the routed blocks and finally route the connections between blocks. Using this method I am only constrained by the routing between blocks. The “ratsnest” view of the board when the blocks aren’t routed hinders my workflow because I see not only the connections between blocks but the connections within the blocks overlapping, making it harder to focus on the nets that matter.
Normally only the last few connections between blocks are constrained because of the need to cross-over several traces from different blocks, which requires many vias within a tight space. It’s the large area of the vias which cause contentions. And since it’s usually a block section that needs to be moved to clear room for this via tangle, the way I structure the layout into blocks makes that relatively easy. So the candidate board happens to have a comfortable amount of space so that I don’t need to worry about moving blocks around to avoid contentions.
Setup
The autorouter setup dialog is accessible from the Route menu, Auto Route sub-menu All… or Setup… The fact there are two items in the same menu opening the same dialog testifies to the fact that few people are using it. Since there are updates to Altium Designer every two weeks and no way to export custom strategies, there’s no apparent point building a library of strategies that will disappear in two weeks.
Altium’s Situs Routing Strategies setup dialog informs me that several connections (to a few fine pitch components) are not routable. In fact, I have set up neckdown rules to make these routable. It’s my standard set of rules, so I know it will work if I route it manually. While this pre-routing report says it can’t route these connections, it actually does route them, at least most of them before it gets stuck on other contentions. There’s a lot of other stuff in the initial report that doesn’t matter. After completing the board 100% there are still a few errors in the Routing Setup Report. Notable how it informs us that neckdown rules violates the rules that they are intended to waive.
I never care about layer direction. There will be a layer direction which can be different in different areas of the board. It’s more pronounced on long thin boards. Since different areas of a board may have different directionality there’s no point creating a constraint that applies to the whole board. I’d rather the directionality be an emergent quality rather than an artificial constraint. Fortunately the layer pattern pass doesn’t care whether this is set or not.
The documentation of the default strategies amounts to “a thing well known” which they certainly are not. What they should have done is state the make-up of each of the default strategies because you can’t open them to see for yourself. So I deduced what I could and posted it below.
If you define a custom strategy you can set which passes are used and in which order. The number of passes is set by adding them multiple times. The dialog can’t be enlarged to read the description of each pass, but there is online documentation for the little it’s worth.
You can set a vague general amount of vias for the strategy as a whole using a slider. More vias is faster, but it’s going to be pretty fast compared to the 386 it was written on. Based on my observation I recommend maximum vias anyway.
There is an Orthogonal checkbox to the right of the Vias slider. Maybe it’s a little faster to do 90 degree corners, then run a mitre pass after, but it won’t make any practical difference. If anything, based on my experience with arc routing, orthogonal corners are likely to cause more contentions and messes of zigzags in a hopeless effort to fit between right angle constraints. So forget orthogonal exists.
The general idea is that the harder it is to route a connection the easier you have to make it for the router. So you have to do passes that do the easy stuff first with heavily contrained tactics, and as the routing gets progressively more difficult the tactics have progressively fewer restraints. Hypothetically, in between the more aggressive passes, you could insert cleanup passes because past routing efforts tend to get in the way, however this doesn’t work very well. There should be a final cleanup/prettying up pass, but again this doesn’t seem to work out. Since modern layouts can take advantage of any-angle and arc routing, the autorouter has fallen behind as it doesn’t support doing these features.
Once you have created and/or selected your strategy, there are a couple of options at the bottom.
Lock All Pre-routes: You should avoid locking pre-routes, otherwise it will not touch any routing that it completed itself on a previous strategy pass. You may think that you don’t want it to mess up work you’ve already done, well then you shouldn’t use the autorouter at all because either it will mess up your previous work or it won’t complete any new connections. If you have some specific pre-routes you don’t want it to touch, then you should lock those manually. If you have Lock All Pre-routes checked it will only try to route the remaining number of routes, if any, without touching anything that’s already there, and none of the cleanup passes will do anything at all.
Rip-up Violations After Routing: This only applies if a strategy contains the Globally Optimized Main tactic which may not be apparent for the default strategies, actually it isn’t used in any of the default strategies. Optimized Main will ignore rules and cause violations in the interest of trying to achieve completion. As a result, if you do not check this while running Optimized Main, there may be a bunch of DRC violations involving incomplete connections. Personally I try to avoid having any more messes to clean up so I would check this box anyway, but never use Optimized Main. Some people have a manual approach of pushing through violations to achieve completion then cleaning up the violations afterwards. This would be the autorouter equivalent.
DEFAULT STRATEGIES
The default strategies can’t be removed or edited or even viewed to see what they contain, and there is no real documentation, so the only way to know what passes they contain is to test run them, so that is what I did. Once you know their structures, you can use them as a starting point to create your own.
Cleanup
Straighten
Straighten
Straighten
Default 2 Layer Board
Fan out to Plane
Memory
Layer Patterns
Main
Completion
Straighten
Default 2 Layer With Edge Connectors
Fan out to Plane
Memory
Fan out Signal*
Layer Patterns
Main
Completion
Straighten
Default Multi Layer Board
Fan out to Plane
Memory
Fan out Signal
Layer Patterns
Multilayer Main*
Completion
Straighten
General Orthogonal (Orthogonal assumed to be set)
Fan out to Plane
Memory
Main
Completion
Recorner*
Straighten
Recorner*
Via Miser (Via tolerance assumed to be set lower than default, but don’t know how low)
Fan out to Plane
Memory
Fan Out Signal
Layer Patterns
Main
Completion
TACTICS FOR CUSTOM STRATEGIES:
Altium documents these in alphabetical order without any categorization, but upon examination they have clear distinct categories which I am putting them in.
EASY / STARTING TACTICS (NO VIAS)
All of these group of tactics are simple and quick and would be performed in the early part of the strategy.
Adjacent Memory – it specifically says simple U connections for adjacent pads of the same net. It routed either 2 or 3 connections in 4 seconds on my reference design. There were about 13 instances but some were ground. The U connections are orthogonal (three 90 degree tracks) regardless of orthogonal setting. Despite running consecutively several times it doesn’t appear to unroute the connections but always reports having routed the same ones as if they hadn’t been routed before. The tracks added are always the same. It does not use vias by definition.
Memory – it specifically says two pads of the same net sharing either the same X or Y coordinate. It completed 347 of 611 connections in 7 seconds. It was able to do 45 degree diagonal connections despite not sharing X or Y coordinates, and pads that were not exactly on the same coordinate but roughly aligned, and dodge around pads in between them. It did a few but not all of the ones that were done by adjacent memory so Adjacent Memory should be done first. This covers most of the easy stuff. It does not use vias by definition.
Clean Pad Entries – it says that it routes straight out the long axis of each pad (not component, which would be preferred for chip components), but doesn’t say anything about the rest of the connection. It says that this pass should always be done after Memory. I got very inconsistent results, often nothing was done.
Layer Patterns – This seems like it would depend on layer directionality being set, but I don’t set this. This pass seemed to perform two passes, assuming one horizontal and one vertical. The first completed 363 connections in 8 seconds, then increased to 422 in 15 seconds. There were some relatively diagonal connections. Repeated passes from scratch produced different results. It did not use any vias.
FAN OUTS (SHORT STUBS TO VIAS)
For both of these types of passes, it uses a via for each node.
Fan Out to Plane – It placed 247 vias but didn’t report any completed connections. In most cases the stubs are too long for my taste, it just doesn’t make them reasonably short, but sometimes bizarrely way too long for no apparent reason. There were several floating vias detached from tracks. It did try to connect pads to inner layers that had the same nets but didn’t get the positions correct so they didn’t actually connect. The split planes were taken from the finished layout so there was definitely clearance for vias to be in correct places. It seems that if the stubs were shorter they wouldn’t block other nearby stubs and it isn’t capable of pushing anything out of its way. It doesn’t reuse vias for adjacent pads or pads overlapping on opposite layers. Normally I would use the same via for an IC power pin and the decoupling capacitor because they are very close together for this reason, but the autorouter does not think this way.
I ran a test of this on a board prepared with splits for +12V and -12V copied from the completed layout. There were four duplicated vias in -12V plane and one duplicate via in +12V plane. +12V and -12V had one unrouted pad each, both clearly over the plane. The unrouted -12V was routed to a via dropped dead in the middle of the split. Ground was a single net plane layer and ten connections to ground were not completed due to obstructions by long stubs. This pass doesn’t push anything and it uses too long stubs in general so it has a poor outcome.
Running Fan out to plane a second time deleted all the stubs when it started.
On the second pass all +12V were completed but one -12V was not, and seven ground connections were missing. Since this rips up and starts from scratch every time, it won’t matter how many times you spin it, there will probably always be unrouted connections.
I see it takes 1 minute 22 seconds to add 76 vias. This pass always takes over a minute because it always rips up and redoes all of its work every time.
Fan Out Signal – I didn’t have inner signal layers on my reference design which was four layer with inner planes. Although it didn’t complete any connections, it placed 591 vias including those to the power planes, so using this with Fan out to planes would be redundant. It made connections that could be made on a single layer without vias which necessitates this being run after the easy single layer passes. It also had the same difficulty blocking itself with too long stubs so some pads were not routed because it insisted to use more space than was necessary and available. This pass takes too long. It takes 6 minutes and 24 seconds and it’s so slow I can watch it drop the vias one by one. It’s not making any deep effort, it’s just dropping a via for each pad. That’s like half a second per via, while Layer Pattern took mere seconds to do hundreds of routes, the difference is preposterous. When repeated, it only seemed to rip up the fanouts to plane of the previous pass, but still took the same several minutes which makes even less sense. The signal stubs were all the same but there were always slight differences in the number of plane connections.
I recall trying to use the autorouter on a board with BGA’s in the past and it wouldn’t perform any fanout on the BGA. It seems to me that its insistence on using too long minimum stub to the via would make it impossible to fit any in between rows of balls. It didn’t place any fanout on a 0.4mm QFN on my reference board.
MAIN ROUTING
Only one of the three main passes (not including completion) should be selected in a given strategy. Completion should be performed after Main.
Main – Uses topological map to find path and push and shove. This sounds like a manual strategy. It completed 211 of 606 connections in 4 minutes and 27 seconds, not including the 339 connections that easy passes did before it. This is the meat of the autorouter. All by itself it did 579 of 611 in 7 minutes and 7 seconds. It didn’t do any of the fanout to plane. Since fanout to plane won’t push I’m sure it would be useless after Main due to the level of obstruction. Fanout to signal took nearly the same amount of time but accomplished nothing. Running Main multiple times completed a few additional connections and the via count decreased. It is necessary to run fanout to plane first. Easy passes are not necessary to be run with this pass, but may be helpful. In fact, since the quality of the routing by Main isn’t great, I would possibly just use the easy passes instead and manually route the rest. It wasn’t able to complete some long and/or contentious connections, although it did reduce the via count again on the third pass, as mentioned I don’t think simply reducing vias for its own sake is worthwhile especially when it isn’t able to resolve any contentions.
Main with Orthogonal set was able to complete 567 of 612 in 3 minutes 52 seconds, slightly less in a bit more than half the time. We’re not talking about a lot of time, compared to how long an antique 386 would take, but the outcome is a mess of right angles that you need to run Recorner on afterwards. I would actually suggest Altium ditch the Orthogonal option and instead integrate any-angle arc routing into the autorouter.
Multilayer Main – Like Main but using inner signal layers. My reference design did not have inner signal layers, but this pass was able to route some connections anyway.
Globally Optimised Main – Like Main but it ignores contentions/violations. I don’t like this. Some people disable online DRC to force routing to complete even if it causes violations. The router can have this kind of strategy for those people. There is an option to rip up violations when routing stops so you aren’t left with a bunch of errors to clean up. I would be sure to check that as it isn’t in the strategy and it probably should be. None of the default strategies use this.
Completion – Like Main but with lower constraints, more likely to use vias or go the wrong direction. By the name, it’s meant to be used as a final pass. Run after Main, Completion was able to add some connections and it used several more vias while Main was actually more and more conservative with vias, but still did not achieve completion of some long and contentious nets. Running Completion successively changes the layout but doesn’t necessarily add connections. I know this board can be completed because I did it, but the autorouter isn’t able to do so. Even if it were, the quality of the routing is poor. It took typically around five to seven minutes on my reference board even if it doesn’t add any connections. A series of three Main and three Completion alternating with either Hug or Straighten between them were not able to complete any more connections.
CLEAN-UP/PRETTYING-UP TACTICS
None of the following clean-up tactics will complete any unrouted connections, they only alter already completed connections. None of these are important if you plan to run gloss over the board afterwards. None of these actually cleanup up any of the problematic loops or zigzags the autorouter creates, so calling them clean-up or prettying-up is a very generous description. Neither does the gloss command for that matter. Problematic areas still have to be corrected manually no matter what.
Hug – Like the gloss command, hug reduces clearance between objects to the minimum. It takes a very long time, just as it says in the documentation and it doesn’t give any idea about its progress so there’s no way to tell how much longer it will take or how far along it is at any given time. Progress never passes the point it started at because this is not a routing pass. It took 27 minutes and 43 seconds to hug 604 connections, and stayed at 604 the whole time, which is about four times slower than Main. It did not do a very good job either. Lots of places where there should be hugging there were loose meanders. There were lots of loops left over. Loops cause contentions because they are effectively two tracks between the same two points instead of one which could mean that one more as yet unrouted track could fit if the loop were removed. None of the default strategies use Hug.
Straighten – Reduces number of corners, large scale zigzag. When I speak about zigzags I usually mean lots of fairly small overlapping tracks, often found near pads. The software seems to have problems removing tiny zigzags because the endpoints of different tracks may not be exactly the same for some reason, but I can’t say that I saw instances of it in the current tests, they existed in the past and are still common when routing manually. Most of the default strategies contain this tactic including especially Cleanup which does it three times. As with gloss, successive passes are necessary to clean up parallel tracks which block one another.
Recorner – If you use the Orthogonal checkbox to use 90 degree corners on a Main pass, you can use Recorner afterwards to turn 90 degree corners into mitered corners. Used twice by the Orthogonal strategy. Adjacent Memory pass uses orthogonal tracks unconditionally but Recorner did a poor job with them. Recorner completes in 7 seconds but doesn’t really produce desirable results, especially if there is a via at a right angle corner.
Spread – this is a very slow pass to pretty up the board with even spacing. I don’t see the point of this even from the point of view of being “pretty”. If you use Hug and have good clearance rules it will look pretty enough. What this will actually do is make spacing inconsistent across the board which doesn’t actually look good. None of the default strategies use Spread.
STOPPING THE AUTOROUTER
There is no apparent user interface to the autorouter in Altium, it just reports to the Messages panel which has no buttons with which to control it. If you need to stop it, you must go to the Route menu, under Auto Route and select Stop.
CONCLUSIONS
The easy passes complete a large percentage of connections very fast and with hardly any screw ups. It’s hard to commend a piece of software for being able to do easy work without screwing it up though, especially when it doesn’t really shine when it tries to do hard work.
The fanout passes in particular outright would not make certain connections due to self-blocking. The assures that no matter how you configure a strategy it is guaranteed to fail to complete 100%. The length of the stubs it uses to connect to vias are consistently too long, making it incapable of performing fanouts on even relatively coarse pitch IC’s. You could either run fanouts after the easy passes, then manually clean them all or what I normally do is copy-paste fanout stubs manually.
After the fanouts you can lock pre-routes and try to run a series of main and completion passes. After running several successive passes, further passes actually reduced the completion. Then manually clean them up afterward or finish the rest manually. The distinction here is whether you prefer cleaning up a nearly finished tangle of Christmas lights or working from a relatively clean slate and personally I prefer the clean slate and think most other people would too.
In general I was disappointed by the lack of any progress indication. It tells you how many connections are left and how many minutes it has been running, but not how many connections it has worked on or how many are remaining, or what passes are left in the strategy, so there is never any way to know how much time is really remaining. Relatedly, the only way to stop it is from the Route Menu which I find highly unintuitive. It really needs it’s own dialog or panel with it’s own stop and pause buttons and a real indicator of progress for the current pass and remaining passes to be performed.
The quality of the routing of the later passes is just as poor as it has ever been. That being said, if set up simply it can do most of the easy routing to save a little time. It still does not have any ability to clean up certain messes that it makes itself and that has always been the problem with it since the beginning.
Future development should focus on eliminating loops, tangles, floating no net tracks, net antenas, zigzags, and unnecessary meanders. These are the exact same problems it had nearly 30 years ago.
Fanout needs to use the shortest stubs possible and needs to be able to push its own work out of its own way.
It would also be nice to see antiquated features that were intended to save time on ancient computers phased out and modern features integrated. Get rid of orthogonal and add any-angle and arc routing.
Get rid of the antagonism towards vias. Nobody has cared about counting vias for ages. Better to pay for a few more vias to get rid of unnecessary meanders that cause signal integrity issues.
Although I am a beta tester, this is not a beta test. The autorouter is a very old feature which doesn’t get much use or updates. What problems it has are ancient and not discussed by advanced users simply because they don’t use it.
Tachyx 