Re: gEDA-user: Design Flow Roadmap starting point

[al davis <ad136@xxxxxxxxxxxxxxxx>]

On Saturday 17 March 2007 00:13, John Griessen wrote:
> David Baird wrote:      (about data tie ins to higher
> abstractions than "just boards")jg I've been thinking (maybe
> just dreaming?) about an extensible system which allows the
> representation of information which has not yet even been
> envisioned, while also providing forwards and backwards
> compatibility as new component representations are devised. 
> For these reasons, OWL struck me somewhat and now I am
> learning OWL and trying to see if I can really make it do
> what I want.  --  A simple example  --  convey to a PCB
> program that a set of nets are actually grouped

That's why gnucap is using plugins now.  I assume that's the 
reason for PCB, too.  I think gnucap's approach is more 
aggressive, in the sense that everything is moving to plugins, 
making the system completely user configurable.

> Stuart Brorson wrote:
>    The discussion about hierarchy should focus on the
> following points:
>
> *  What kind of data structures are desirable?  How would
> they look? Right now, the main data structure for a schematic
> is a linear linked list of graphical objects (for each
> schematic page).  Some list items point to others (i.e. to
> support component attributes). How would that change to
> support hierarchy?
>
> *  ONce a datastructure is decided upon, then what does the
> file format look like?  Note that our current file format
> maps fairly closely onto the internal data structures. 
> Preserving this close mapping is a desirable goal. 
> Therefore, the data structures defining hierarchy should
> more-or-less dictate what the file format should look like.

You have the order backwards.  Design the file format first, 
then the data structures.  The file format should be designed 
as a language for expressing what you want to express.  If the 
thing being expressed is a printed circuit board, the language 
should be meaningful and expressive in that context.

If the data structures are already designed, I still say design 
the file format "first" in the sense that it should ignore the 
data structures.

Fitting the file format to the data structures permanently locks 
you to the mistakes of the first cut.  Designing the file 
format description language first leaves you free to change the 
underlying algorithms and data structures later.

File formats that are data structure dumps cause big problems in 
the long run.

I still believe we need an interchange file format, that should 
be a VHDL derivative.  VHDL has most of the capabilities 
needed, and is an industry standard.  If something is missing, 
we can add it, and propose it back to the standards committee.  
They might even welcome it.

gnetlist really needs to be redone, from the ground up.  This 
VHDL based intermediate format is the way to do it.

gnetlist has served us well so far, but we have learned a lot by 
doing it and using it, and it is time to move on.

> *  How should gschem behave once hierarchy is architected in?
>  Right now you attach a source= attribute to a symbol.  Then
> you do "schematic down" on that symbol to dive into the
> sub-schematic.  Is that OK?  Or what's a better scheme?
>
> And how to handle re-use blocks?  That is, if I have a
> sub-schematic which I instantiate four times, how should it
> be refdesed in the netlist?  If I dive into one of the four
> instantiations and edit it, is it OK that the other three
> instantiations are also updated.
>
> A list of use-cases would be helpful here.
>
> *  Similarly, how should gnetlist behave?  A use-case list
> would be useful.

Any extraction should preserve hierarchy, in hopes that the 
target tool also benefits from it.  If it doesn't, you need a 
separate flattener pass, separate from the translation.

Regardless, the translation must be 100%, lossless, in both 
directions.

gschem attributes need to have types.  The type is just a 
string, but important.  That way one type can be those passed 
to a simulator, another can be those passed back from the 
simulator, etc.  Since the type is just a string, new types can 
be added at any time.  An attribute should be able to have 
multiple types.


> *  Finally, how should PCB behave with a hierarchical
> schematic?

Right click on a symbol, select "go inside", and another drawing 
opens up showing what's inside.  gschem also should act this 
way.



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