| ID: | 4266 |
| From: | ge...@igor2.repo.hu |
| Date: | Mon, 27 Jul 2020 11:17:06 +0200 (CEST) |
| Subject: | [pcb-rnd] project state update + external autorouters |
Hi all, weve switched from cleanup to feature development phase. During the cleanup I've made good progress with the librnd separation and the menu system upgrade for more modularity. In the feature dev phase there are two smallish features on the TODO, and other than that I am cocnetrating on route-rnd, our external autorouter. More about the autorouter and how this effort will make pcb-rnd _smaller_: I know, I know, you don't want to use an autorouter at all. At least, according to my informal surveys, I am perfectly aware of the fact that majority of pcb-rnd users don't want to use an autorouter, and even those who can imagine to use one prefers something closer to assisted routing (e.g. push & shove). Maybe it sounds a bit wierd, but at the end the main benefit of having our own (external) autorouter will help us cleaning up the code and have less legacy/historical/junk in pcb-rnd regarding to the largely unwanted autorouting feature! Rationale: 1. We have a built-in router, the original one, from the early 2000s; by now this is only half-working. But if we are honest, it was never really fully working even in geda/pcb: I learned the hard way that it didn't really handle diagonal lines (or even arcs), so even the rat drawing code had to had ugly workarounds that made rats less optimal for non-autorouter-users as well; and then the resulting routed tracks are so bad that we have the djopt plugin pretty much dedicated to clean it up using local optimization. 2. We have bridges to external autorouters, but non of them are good enough that I'd safely recommend new users to use them. We have one to freerouting.net, which is a java app (for many that just means "PITA to run"); we have a bridge to c-pcb which is small and easier to run, but is half-finished and I lost hope that it would ever get to the level we need. 3. We used to have a toporouter by Anthony, which was also half-finished, depended on a local fork of a large triangulation lib and had zero chance that anyone would ever touch it again. I got rid of this one long ago. 4. We have a few, currently defunct or half finished or abandoned assisted routing tries (acompnet, skroute, jostle). In a more generic sense I regard these as autorouters too. So we have a lot of code, but not a single real good, well working solution. After reading a lot in the topic of autorouting, including geo based routers and topological routers, I am very confident that autorouting is a problem too big to simply fit within pcb-rnd. Plus I am also sure that all the complex data model and infra in pcb-rnd is suboptimal for autorouters. It's because pcb-rnd is a PCB editor, so it has to deal with tons if tiny details related to fabbing and footprints and parts and metadata. For autorouters, this is pure noise. So they either go and rebuild the whole board in a simpler model, or they go on constantly implementing workarounds and ignores for the fab-related fuzzyness. At least that's when you have an internal autorouter plugin. With an external autorouter solution pcb-rnd exports the parts of the data model that are relevant to the autorouting and the router deals only with that. The plan is (part of the NGI0): 1. I've specified a tEDAx file format for communicating from a PCB editor to an autorouter, and back 2. I am now building the main infra of route-rnd, a stand-alone modular autorouter, working with this format 3. I am implementing a very simple router algorithm plugin that works with 2+ layers, having horizontal-only or vertical-only wiring on each layer; this one will be usable when you have a few, sparsely placed parts and board space and via cost are non-issues; typical for simple arduino shields; typical for those where our original autorouter or c-pcb also worked. But although it would result in an autorouter usable for those simple cases, the main goal is rather that I have something I can finish and test the whole infra with 4. during my research I found a few easy-to-implement algorithms for simple geometric routing. I may try to implement one of those too. 5. Then I can sit down and rewrite the topological autorouter within route-rnd. When I'm finished, I hope we will have something that's an alternative to freerouting.net. Although it will probably take many years to catch up with them, I hope it would be a bit better than the original geda/pcb toporouter or the built-in autorouter plugin we have now. 6. Once we have the toporouter working within route-rnd, I will start removing the old junk from pcb-rnd. And that's the main goal of the whole thing: to refactor things and separate the huge/complicated/not-really-fitting-in autorouting topic from pcb-rnd to external code. So I'd fully remove the current autorouter, and the half-finished assisted routing plugins, and the c-pcb bridge too. The dedicated freerouting.net bridge would be removed too, because by then we'd have a real complete io_dsn that could be used for the same. 7. Long term I _think_ assisted routing will fit more into route-rnd than pcb-rnd too, and we would have an optional real-time link between the two for this purpose. So at the end we will have smaller, simpler pcb-rnd. For those who don't ever want to use autorouting this is already a benefit, a lot of half-working and/or never used code removed. For those who use autorouting, the new setup will not make a big difference in how autorouting is done on the user level, but hopefully will improve the quality of the routing. And for those who want push&shove, I know a lot of users want that, while I am going through all these, I hope I will learn enough of topology and routing that I will be in a good position to finally sit down and solve that after this effort. Best regards, Igor2
Reply subtree:
4266 [pcb-rnd] project state update + external autorouters from ge...@igor2.repo.hu