Re: gEDA-dev: SoC: Gerber, DRC, gsch2pcb and D-BUS

[Peter Clifton <pcjc2-at-NOSPAMcam_dot_ac_dot_uk>]

On Fri, 2007-03-23 at 16:14 +0000, Justyn Butler wrote:
> On 23/03/07, Peter Clifton <pcjc2@cam.ac.uk> wrote:
>         I'd have said #1, simply as #2 relies on gnetlist, which is
>         being worked
>         on by various people, at least in design. I can list Steve
>         Meier, Peter
>         Brett and Myself as those considering new data-structures for
>         libgeda 
>         and the netlister.
> 
> But isn't gsch2pcb simply using gnetlist? Whatever happens to the
> internals of gnetlist, will it affect any work on gsch2pcb?

Yes and no. Assuming gnetlist provides the same external interfaces,
then gsch2pcb can behave in the same way it does now.

Currently, gsch2pcb uses a gnetlist backend to output a PCB file, using
the scheme backend gnet-PCBboard.scm.

Since the PCB file-format is PCB's, and may change, it is wiser to use a
defined API to PCB to make PCB write the file. This entails adding to
PCB's action interface as necessary, and making gsch2pcb output a script
of actions rather than a "PCB" file. This could be executed on the
command line, or via DBus.

Work relating to live interaction between gschem and PCB using DBus will
benefit from netlisting changes (certainly cross probing and back
annotation). 

In the forward path (Peter Brett and I put together a graphical frontend
to gsch2pcb which uses gsch2pcb's output to feed changes into a live,
PCB layout. That didn't particularly need gschem to understand netlists
though.

> What exactly is libgeda?

libgeda is the library which gschem, gattrib, gnetlist, gsymcheck (and
others)? use for accessing your design.

Currently (in gschem at least), this is mostly graphical. For the
integrated functionality required in cross-probing / interactive
simulation / back annotation, we require libgeda to give gschem, gattrib
etc.. the ability to understand the netlist (circuit representation)
underlying your schematic drawing.


>         We want to retain the scheme backends for output of course,
>         leaving the 
>         project to write the netlist->PCB translation bit as a PCB
>         action script
>         (the clever bit will be doing updates to an existing
>         schematic), then
>         push that over DBus.

> Sorry but I'm pretty confused by this last paragraph. When you say
> "the project" do you mean a SoC project, because I thought you were
> suggesting this shouldn't be attempted given the other work being done
> in the area? 

I did mean the SoC project. I'm not suggesting it shouldn't be
attempted, just trying to clarify the potential scope.

The email from Al Davies which suggested using a VHDL intermediate file
format, I believe was a little un-related to your proposed project.
There has been some discussion recently about file-formats for designs,
and the possibility of using VHDL as that format.

I'm not opposed to this - it can express the entities we want, and Al
has suggested making a translator between our existing formats and some
VHDL representation.

On the other hand, I don't think it would give any immediate benefit to
the gsch2pcb design flow.


> Lastly you mention D-BUS, what is the status of this in gschem and
> PCB? What I mean is, what about a SoC project to add more to this area
> (say in conjunction with gsch2pcb, though as DJ says the script could
> also still be sent by directly invoking PCB). 

There is working DBus support in PCB. Currently this consists of a DBus
method to call PCB actions. We might like to extend the list of actions
available to allow increased flexibility from this interface.

gschem has no DBus support, and it needs cleanup before one could really
contemplate adding it. gschem already has some scheme scripting, and one
way to proceed might be to expose an interface via DBus to that
scripting.

More usefully, it is better to refactor libgeda and define an API which
can be exposed via C, scheme, DBus, and other scripting languages -
directly modifying the underlying design. The design effort is ongoing.


> It seems to me that it is not that easy for gEDA to unanimously agree
> on what is more important. It is for this reason I would like to
> submit more than one proposal, if possible, to give more time to
> decide which to prioritise.

You may have hit the nail on the head there. You'll find many people
give opinions and have their own agendas.. in time you'll figure out
what those are. (Can you guess my current areas of interest? ;)


-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)


PS.. the answer to the above question: I'm interested in cleaning out
and re-factoring the infrastructure in libgeda to provide a useful
framework for future development of the tools.




_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev