gEDA-dev: SoC Hopeful

[Peter Clifton]

On Sun, 2007-03-18 at 13:40 -0800, Steve Meier wrote:
> Wow, do we need a uniform way for each backend to define what info
> should be embeded within a "part"? Seems on the first thought to be a
> good idea. Would gsymcheck be a good starting point?
> 
> Steve Meier

Peter Brett and I proposed this at CUED last summer, and a bit of some
time working through the preliminary design concepts steps needed to
offer the GUI to fill in the specified attributes.

We were thinking more generically, along the lines of having a list of
required, recommended, and optional attributes which would get offered
at different levels in the GUI, along with a pluggable / scriptable
validator / chooser interface. I'm not sure we ever came up with a good
way for the back-end to specify which design flow you're using, or
worked out at what point (or in what form) the user would input their
design flow intentions.

For text based, yet syntactically significant attributes (say some
parameter line to gnucap or ng-spice), we could define some scheme code
or external helper program (perhaps called via scheme) to validate the
user's input.

For footprints, an external helper program would be opened via an "..."
button, allowing you to graphically select a footprint. (Ideally it
could stay open in the background as desired after this, and be
communicated with via IPC - avoid it having to keep saving and restoring
its state.)
 
Perhaps we ought to introduce "parts" side-by-side with plain "symbols",
a least during testing. The idea of a "part" in a parts database locks
many specific attributes down explicitly, defining them as integral to
the part - and adding them to the symbol as it is instantiated, or to
the schematic. If the object in the schematic is a part - these
attributes should not be editable.

This moves / shares the need for validation / checking of required
attributes into the parts database as well as gschem. (A part should
essentially be complete for a given task.

We might have a particular 741 opamp part which is complete for
schematic drawing, PCB layout, circuit simulation with gnucap,
purchasing ). It might not flag up as being complete for ng-spice.

I believe it is an important opportunity to introduce hierarchy in the
parts manager. Take the NE555. There might be many many different
vendors of this ubiquitous timer, and it seems like rather than
duplicating the database entries entirely, we ought to define some
generic 555 timer part (not completely specified for purchasing or
perhaps even its package), and then have small entries which inherit
from this, and specify the remaining information.

The parts manager is something I've spent a lot of time thinking about,
and perhaps I'm thinking too flexible.. but it seems like a non trivial
design task.

Regards,

-- 
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!)