X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Fri, 12 Oct 2018 10:51:21 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu cc: Stefan Salewski Subject: [geda-user] Re: pcb routing (your toporouter) + pcb-rnd In-Reply-To: <1539329167.2448.41.camel@ssalewski.de> Message-ID: References: <1539329167 DOT 2448 DOT 41 DOT camel AT ssalewski DOT de> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hello Stefan, (I originally sent this mail in private, because it has nothing to do with gEDA. Since you sent your aanswer to the mailing list, I'm going to answere here. I think some users would prefer if we moved this back in private - if you agree, please answer in private.) On Fri, 12 Oct 2018, Stefan Salewski wrote: > I heard about your pcb-rnd already, but never found time to investigate > it any further. > > Still written in plain C and using GTK? Plain C (ANSI C89, except for the gtk part, which is C99), with multiple HIDs, one being gtk2. We also have lesstif/motif and an almost working gtk3 HID, the good old batch (cli) HID, a half-working "remote" (networked) HID, plus I will write an SDL HID later on. Thus pcb-rnd is _not_ a gtk app in any sense. We are just using gtk (among other options) for drawing. We could add a HID anything that has C bindings and some developers wanting to spend time. I am actively reducing the HID API these days to make adding new HIDs easier. > > I have not followed the geda mailing list in the last few years, so I > may have missed a lot... > > Some years ago, the geda project appeared to be nearly dead. gschem has forked (lepton-eda). pcb forked too back in 2013, I mean pcb-rnd was originally a pcb fork (but it's much more by now - we have replaced most of the major infrastructure, including almost the entire data model; the line-by-line code change stats is close to 74% in the code base). Whether geda is dead, you should judge for yourself. As an user, I switched to pcb-rnd long ago (obviously) and I am switching away from gschem too. As a developer, after really scaling up pcb-rnd in 2016, I kept on pushing some ideas as of how to get gEDA pull a similar trick - to no avail then gave up and moved on (see coralEDA). > Interest in autorouters was never really big from geda dev/user side -- > you may still remember Antony Blake's GSOC router? For my Router > interest was nearly zero. pcb-rnd is not part of geda in any way. My interest is from coralEDA, which is a different effort, has nothing to do with gEDA. Our userbase, developers and preferences differ, and there is active interest for external autorouters here. As far as I remember PCB's topo router never really got finished (could it place vias?). It was definitely hard to maintain in pcb-rnd. Having to have a local copy of the gts lib didn't help. Plus the large code size, insufficient doc (references to papers not freely available instead of describing the algroithsm used). So after a while I've asked the community and there was no large scale objection so I removed the toporouter from pcb-rnd. At the moment we have the old PCB autorouter built in that still works and we have support for two external autorouters (c-pcb and freerouting.net). These days I'm looking for more autorouters to provide alternatives. That's why I contacted you. > As you know my router was coded in Ruby -- a language fine at that > time, but not first choice today. Today we have some really nice modern > languages like Go, Rust, Crystal, Nim and some more. My favorite is > currently Nim, easy to use like Python, fast as C and due to static > typing better suited for larger projects than scripting languages like > Python or Ruby. > > So I indeed intend to convert my router to Nim and continue it some > time. With external autorouters we do not have language restrictions, you can use whatever you like. At the end, in coralEDA, we are more interested in how the tools play together, and how we coordinate development in a way that benefits the user. > One problem with such a "Rubberband-Router" is that it may need manual > intervention, so using it as a fully external router is a bit > problematic unfortunately. For example it may be impossible to route a > board completely, due to limited space. So moving some parts may be > necessary. That is easily to do interactively, but problematic to do it > fully automatic. > > So the ideal goal would be to have a schematics tool and a PCB tool > with autorouter integrated. But that is a lot work. Sorry, we disagree on this. pcb-rnd is moving in a direction that we are removing _all_ autorouters long term and we have no plans to integrate schematics editing. Our ideal goal is different. Ours is an ecosystem of independent tools developed in a coordinated effort, not one big integrated tool. So we are building an ecosystem, following the good old UNIX traditions. The tools are typically written by independent developer groups using different programming languages and tools. I imagine autorouting would work the same way schematics is done in a different application, and we have nice, incremental forward and backward annotation. That's why we don't need to integrate any schematics editor with pcb-rnd. We are building up the same mechanism with diffrent external autorouters at the moment. The user generally edits in pcb-rnd, gets the GUI from there, and when something needs to be routed, the external router is called. Not necesarrily called to route the whole board, the request can be partial. Are you interested in this multi-tool ecosystem idea with your existing autorouter or with a new one you write in whatever language? > OpenGL, but gschem was using Cairo. There are two new drawing toolkits, > intels FastUIDraw and vkvg. I will have to watch for progress there. In the ecosystem setup, an autorouter doesn't need to have an interactive GUI at all. It can have one, if it wants to, or it can have an optional, simpler debug draw/dump interface. Or it can be just a command line tool. What's important is how it does its job and whether it can communicate to other tools in the ecosystem, like pcb-rnd in this case. > > One major task is of course simulation -- have not heard much from > gnucap side in last years. Does KiCad have fine simulation already? In coralEDA we have xschem. It does a good job on schematics editing and it has simulation using different sim backends. Development is very active, even fancy feature requests get implemented fast. As it's coming from VLSI background, it scales well doing large system of schematics. So pretty much the same ecosystem story: separate simulators and schematics editor, communicating. Later on we will probably have other schematics editors as well, I am in contact with some projects. We are constatly exploring existing projects to extend our ecosystem. (Yes, I checked out petEd too, but decided to ask about the autorouter first, as that seems like a smaller effort to get in). > And what is about > > https://github.com/carrotIndustries/horizon > > I think that is written from scratch in C++. By one single person, must > be a really smart guy. Looks like the opposite of pcb-rnd and coralEDA in almost every aspect/goal. There are also a few web2.0 efforts started the past few years. I think these projects are targeting different audience. We, at pcb-rnd and coralEDA, are targeting UNIX hackers. So I'm happy with the direction pcb-rnd took, and coralEDA is going in a good direciton too. While the ecosystem idea is less popular than the "one big integrated tool" these days, projects are joining coralEDA, and I am happy with the rate we are growing at. Thus the question is not how we want to start over the whole thing differently, because we are happy with the path it is taking. The question is whether you are interested to join in the (already existing) ecosystem effort with your autorouter or not. It's okay if you say no, e.g. because you are more interested in some all-integrated tool. If you say yes: honestly, I'm more interested in getting the existing code work and deliver useful functionality than in a rewrite in whatever more modern/fashionable/cute language. But of course it's up to you. TIA, Igor2