Re: gEDA-user: Design Flow Roadmap starting point

[Steve Meier <smeier@xxxxxxxxxxxxxxxxxxx>]

John,

Keep this up and we are not only going to think you are paying attention
but that you are taking notes as well.

Steve Meier

John Griessen wrote:
> John Griessen wrote:
>> So,  "What do you want?
>
> The gschem gnetlist PCB gsch2pcb gattrib gerbv  wants mentioned
> recently and needing discussion are:
>
> Steve Meier:
> 1) hierarchical data and file structures (xml or other)
> 2) an integrated hierarchical netlister
> 3) use of a better supported scripting language
> 4) a method of dynamically partioning devices into meaningfull symbols
> 5) a method of communicating between the schematic design and the layout
> program on issues of slot swapping, i/o pin swapping, differential i/o
> pin swapping, bank swapping
> 6) strong drc
>
> > My plan for dealing with long refdes names e.g.S1/S2/S3/U3 is to hide
> > the refdes and create a large box on the silkscreen which is labled S1.
> > Then inside the S1 Box, a smaller box on the silcrean labled S2 and
> > inside ths S2 box an even smaller box labled S3. The device inside the
> > S3 box will have a silk screened comment near it that states U3.
>
> Svenn Are Bjerkem wrote:  (about geda installer)jg
> For real day-to-day work the engineer should be
> able to decide himself what tool he wants to use....
> it should be enough to
> run a command to have it installed.
>
> On 3/4/07, Dan McMahill <dan@xxxxxxxxxxxx> wrote:        (about
> multiple flows)jg
> > I think designing the tool up front to explicitly deal with and support
> > 2 different back end flows (layout and simulation in this case) is very
> > important.  Presumably that will be a good vehicle to making sure it
> can
> > extend to many back end flows.
>
> 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
> > together to form the address bus of a microprocessor system.
>
> Dan McMahill wrote:  (about using gnetman work already done to get
> hierarchy )jg
> I guess what I'd hate to see is a lot of work put into improving
> gnetlist (which needs improving)
> only to find that the underlying database structure and methods for
> accessing it still
> aren't complete enough, fast enough, or scalable enough.
>
> 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.
>
> *  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.
>
> *  Finally, how should PCB behave with a hierarchical schematic?
>
>
>
>
>
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
>



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