This next design is a smaller board, less complex, density about the same, but with a QFN part. Note that my board density is partially due to the off-board connectors defining the minimum size board, and a tradeoff in size to make it easier for me to hand place the smt components. Plus, not cramming parts too close together for these prototype PCBs allows for cuts and jumpers during debugging.
Here is my manually routed board. I think it flows fairly nicely. The 6-pin header is an ISP programming connector, so I cannot reassign pins on the 20-pin MCU to improve routing. There is also a trend showing up in my boards. I like to put a rectangle on the bottom and assign it to GND to give me a ground plane. Not really necessary on these tiny, low frequency board. Above 16MHz is my rule of thumb for where ground planes are a must.
But it is a force of habit for me, and it saves me from routing the GND net.
I tried routing this board with the routing grid set to 10, but the Eagle CAD router refused to connect to any of the QFN pins. The pins are .5mm spacing. So I tried setting the grid down to 2 and even 1 mil. Still it wouldn't route for some reason. And, routing with a tiny grid gives the algorithm too much freedom. Instead of routing in a few seconds, it can take minutes (on a small board).
So I "helped" by doing short routes out from the pins. A secondary benefit is that this prevents the autorouter from doing anything stupid right up next to the package, like putting in a via that blocks adjacent pins.
That puts the end of the signals on-grid, allowing the autorouter to do its work. So I set my DRC rules to 10/10 (width/spacing) and the routing grid to 10.
Anyway, this isn't great. There are a couple unrouted nets. One is easy to fix, but the other is going to take some work. The routing is noticably less optimal my manual routing. Also note the two vias the router still managed to put close to the QFN. Not good for solerability or rework. There are some goofy squiggles on some nets. If I wanted to help the autorouter some more, I would rip everything up, then route the QFN pin 4 up to the SOT23 and give it another try.
I hand routed this board in under an hour. Cleaning up the autoroute is going to take a fair amount of time, but well under an hour. So again the autorouter is a time saver with acceptable (not optimal) results.
Next, I have a board that has a bit more critical routing requirements. This board is a capacitive touch controller. The signals going to the headers on the right of the board need to be layed out to avoid too much capacitive coupling between signals. The board as placed is a little more dense that the first two, and it could be compressed even more. I left it a bit loose so it would be easier to manually route. I have to admit in fairness to the autorouter, I took two evenings to route this by hand, which included starting over from scratch at one point to make the board larger and easier to route by hand.
Without going into too much detail, there are some considerations in the routing to make the power rails clean, and reduce coupling between the touch sensor signals. The autorouter isn't going to know about those.
Another QFN fine pitch part, so I hand routed some stubs for each pin just so the autorouter would have any chance to route the board.
Next is the autoroute results:
One unrouted net. The autorouter managed to put in some vias and routes to really block that signal from routing. I manually routed it, but it took about 12 minutes of shoving stuff around. The spaghetti routing on the right side of the board may or may not be acceptable, electrically, for the touch sensor signals. I'd have to fab the board and try it to see if the capacitive touch is impaired. It is certainly not as good as what I did, but then the autorouter doesn't know the special constraints in that area.
The routing on the left side of the board isn't too bad. The power signal is routed similarly to what I did, with no vias. VCC is pin 3 of the QFN going to the SOT23 regulator without any vias.
What I might do with this board next is to leave some of the autorouted nets as-is, and rip up a lot of the nets on the right half of the board so I could clean them up.
Conclusion
The EagleCAD autorouter can be useful on some boards. The autorouter was able to route these boards with just some very basic tweeking (routing grid set to 10 mils instead of the default 50) and routing help (fine pitch SMT parts seem to be problematic). This router doesn't support tagging nets as differential pairs or critical nets, so there is a clear limit to what it can do. For hobbyist prototype boards, if you lay out critical nets by hand, I'd say it can be a useful tool to save you some time.
1 comment:
Thanks for these posts about the Eagle autorouter. I'm teaching myself how to use Eagle, and I find your posts very informative.
I'm actually a programmer, though I do electronics as a hobby and recently started a job that combines both. From my point of view as someone coming over from the software side, I view the choice to autoroute or hand route as being analogous to the choice of whether to write a program by hand in assembly, or let a compiler do it.
I can write assembly by hand, and I can do a better job than a compiler can, but it isn't the best investment of my time. In order to be productive as a programmer, I have to find ways to get the computer to do ever more of my work for me.
So when I set down to learn Eagle I tried the autorouter and said, wow, this thing does some really goofy stuff that I don't like. Now I have a choice - I can either learn to hand-route, or I can fiddle with the autorouter until I figure out what makes it tick. If I hand-route I can make one board come out well, but if I learn the autorouter I can make all my boards faster.
One thing I learned from this, while laying out a compact surface mount board, is that the autorouter actually does better the tighter you pack the components in. I guess it has less room to do something goofy.
Thanks for sharing the tip about brining nets out partially & letting the autorouter complete them. I like to say "rip up all" and re-autoroute the whole board every time I move a component (I'm serious about making the computer do more of the work - and I have a fast CPU!) If only there were a way to mark "my stuff" different from "it's stuff" so that I won't lose my own routing. Perhaps put the hand-routing into custom device footprints? I did a similar custom-device trick to ensure the connectors for a board that mates to another board line up right: rather than laying out the headers that connect the boards by hand, I made a giant "device," the size of an entire board, that contains the mating headers. That way I don't have to worry about accidently moving a board mating header out of alignment. With my experience with software architecture, I am always looking for ways to abstract the parts that change from the parts that don't.
Post a Comment