[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Design Flow Roadmap starting point



>From PCB, I would like to seperate the hierarchy from the rest of the
refdes. I would like to be able to layout a hierarchical section. I
would like to be able to save that section as a seperate collection. I
would like to be able to paste a copy of that section into a larger pcb
layout and only have to change the top of hierarchy string to correctly
interact with the netlist.

I would like to be able in the netlist to tell pcb which slots are
swapable, which i/o pins are swapable and which pin pairs can function
as differential pairs (these last two have to be able to be limited to
specific banks) such that pcb could correctly change the net list
itself. Then I would like PCB to be able to tell me what pins and in
what order the pins were swapped so that this could be imported back
into the original design.

While I am at it. PCB should be able to do hidden vias, buried vias and
micro vias... Did I mention the ability to cut out areas of layers such
that I can resese components into lower layers?

Finaly I could use all of these by, ..... say next Tuesday.

"I'd gladly pay you Tuesday for a hamberger today"

Thanks,

Steve M.

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