delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2018/10/12/04:52:51

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 <mail AT ssalewski DOT de>
Subject: [geda-user] Re: pcb routing (your toporouter) + pcb-rnd
In-Reply-To: <1539329167.2448.41.camel@ssalewski.de>
Message-ID: <alpine.DEB.2.00.1810120933180.21900@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1809301737010 DOT 21900 AT igor2priv> <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
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

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019