Specifying a PCB

A surprisingly large number people designing circuit boards do not include any specifications with their gerber files. Specifications have historically been kept in what’s called a readme file, which had to be created manually or copied from someone else. For those who do include specifications, they are often lacking in detail or contain too much irrelevant detail. When you order a burger, as soon as you start specifying things, the price starts going up. Nowadays a good fab service is going to ask questions, just so they don’t end up remaking your boards.

When I order a PCB, the release to production is contingent on approval of panelization unless the design is already panelized and I always require testing. I would typically write specifications on a single line, for example:

4-layer, 1oz ext, 1/2oz int, 1/16″ FR4, green soldermask, white silkscreen, ENIG.

This is all a good fab really needs to know. Wait, I didn’t specify any stackup. Not specifying a stackup isn’t the worst thing. How can that be? First of all, in the vast majority of cases the impedance is going to be 50 ohms. If you ask a fab to produce a different impedance they are going to ask for money and suddenly there is no impedance requirement anymore. So anyway, the fab has a standard stackup they use and that’s what you want and that’s what you’ll get unless you already knew that it costs more to get something different and said so in your readme.

The worst thing is the FR4 itself. FR4 is the substrate, the glass filled epoxy making up the core of the PCB between the layers of copper. Back in the day this was no big deal until the RoHS standard came along and people started using lead-free solder. Now you can get special lead-free solder with lower melting points, but often SAC305 or SN100C is used and so the board has to be processed at a higher temperature. RoHS is a standard banning chemicals, in this case lead, so if someone says that it complies with RoHS all they are saying is that it doesn’t contain lead and other chemicals and that’s it. What you need is FR4 which can withstand reflow temperatures required for lead-free solder.

In order to get FR4 that withstands lead-free soldering most people specify Tg140. Tg140 means that above 140°C the epoxy starts to become squishy and the layers of fiber can start to come apart (delaminate) due to thermal expansion. This temperature is supposed to be 25°C above the maximum operating temperature of the board, so in the case of Tg140, the maximum operating temperature is 115°C. Solder on the other hand, especially lead-free solder melts at a temperature far above this. SAC305 reaches liquid state at 221°C. So what good is it to say Tg140 when you need to withstand 221? Almost nothing. Before lead-free solder, typical FR4 was rated for Tg130 for an operating temperature of 105°C which covers most commercial grade components. By asking for something better than Tg130 you are just hoping that it’s good enough for lead-free soldering, and in most cases it barely is.

By barely I mean that if you are mass producing and throwing out anything that doesn’t work you won’t care either way, but I work with people who produce a thousand or less and try to salvage anything that doesn’t work, especially prototypes. What you want in this case is to say is T288 of 5 minutes or more, which means that the FR4 has been tested to not delaminate for at least 5 minutes at 288°C. If you are thinking of pulling a complex IC off a board using a hot air solder station, how long do you think you need and at what temperature? There are lots of brands of FR4 and different Tg ratings. You may find one brand’s Tg130 is good enough, but another brand you have to go with Tg150 to get something that will be reliable, so just giving a Tg rating isn’t good enough. In most cases you won’t even know which brand of FR4 is used, but it will almost certainly be a Chinese brand and that should make you pause.

For example, Shengyi S1000 is Tg150 and has T288 of 10 minutes. Shengyi S1141 is Tg140 however T288 is only 2 minutes. Kingboard KB-6160 is Tg130 and T288 is 3 minutes and KB-6164 is Tg140 and T288 is 15 minutes. So Kingboard’s Tg130 is sort of better than Shengyi’s Tg140. Most suppliers I have used use either Kingboard or Shengyi. PCBCart.com uses Shengyi S1141 but SAFE-PCB.com uses Shengyi S1000 so I prefer SAFE-PCB. It would be nice to use someone who uses Kingboard Tg140, but in many cases you won’t know what brand of FR4 is used unless you ask directly.

There are several other brands of material of varying quality and people demand cheap and don’t know what matters. Some people resort to asking for Isola or ITEQ which will cost you when you don’t really need it, such as high speed or high temperature. The vast majority of products are running microcontrollers at barely a hundred MHz and don’t reach commercial temperature rating because you will get sued if someone burns themselves.

Usually specifications contain lots of superfluous and sometimes outdated details. Fabs might suggest certain things be in there, but it’s usually deducible from the files if it’s relevant at all. For example, people will say things like LPI or SMOBC without knowing what they mean.

I have never seen any situation that mattered whether a board was produced using LPI vs the alternative DFSM or more modern digital printing, because when you receive the board the soldermask is already cured. The reason for this specification is because in the past there were simpler ways of screenprinting boards more suitable to making T-shirts, and they don’t even make T-shirts this way anymore either.

SMOBC would only need to be specified if you are using HASL finish which you probably shouldn’t be using unless your board is an antique with only through hole or maybe just 1206’s and SOIC’s. And on top of that you are probably using solder containing lead. Lead-free solder is notorious for not flowing, but solder flowing under the soldermask is the reason why SMOBC was originally specified. Almost certainly you don’t need to ask for soldermask over bare copper because that is the defacto standard process.

Dimensional size of the board is a nice to have, but if you have dimensions in your drawings, that is enough. There is no need to manually type out copies of the same information which is where errors really come from.

Trace/space? Back in the day making 6mil traces was expensive. Now it’s not so who cares.

Numbers of holes, hole sizes, number of drill sizes. Back in the day, through hole boards had more holes and they used to charge by the hole. It was also a bigger deal (more expensive) to make small holes. Having drill drawing and table in your gerber files is good enough.

Layer filenames are fairly standard. The only problems might be the mechanical graphical layers which usually aren’t used for manufacturing. If you want them to manufacture something with them, like a special mask or controlled-depth milling, you have to explain exactly what you want and it’s going to cost extra.

Most people order PCB’s online and when you do that usually the online order form has all the specifications right there. If you are maintaining readme files manually, it’s tedious and prone to human error. Because of these two things there will sometimes be inconsistencies between what the specifications say and what the order says, leading the fab to ask questions. So if the fab is going to ask all the time no matter what, it actually deters people from good habits to avoid what seem to be unnecessary questions and back-and-forth delays.

The best way to avoid problems is to tell the fab on the order form to disregard the specifications on the order form and just use what the readme or specifications file says, and you may still have questions but they only refer to the specifications rather than any differences between them and what’s on the the order. If you are in a situation where the person making the specifications and the person ordering the PCB are not the same person, you probably wouldn’t expect the person doing the ordering to make judgements on the specifications.

Layer Stack Legend generated automatically in Altium Draftsman

Readme files can be supplanted by automated outputs from more advanced modern PCB design software. I use Altium’s Draftsman document and render it as a PDF in my OutJob which serves as my readme. I use project parameters to hold the specifications so don’t have to edit the individual files. I use an Excel sheet to define my specifications and just paste them into Altium’s project parameters, rather than try to define them all manually.

Altium Designer’s Situs Autorouter

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.

The highlighted section in the top half of this image has no business existing.

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.

Fan out to Plane – Not Great

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.

Recorner After Adjacent Memory

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.

There are two loops, a floating net, one antenna, and lots of unconnected decoupling caps just in this one picture which was taken after several passes.

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.