Mail Archives: geda-user/2018/10/12/04:52:51
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 -