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 <[EMAIL PROTECTED]> 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 [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
