[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
gEDA-user: Design Flow Roadmap starting point
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