Re: gEDA-user: Solving the light/heavy symbol problem
On Tue, May 24, 2011 at 01:43:08AM -0400, DJ Delorie wrote: Hierarchy isn't the only reuse scenario. Consider transition from breadboard to prototype to production. A top-level schematic might not change, even though attributes of parts might change (different packages, tighter specs, ...). In that case, the instance-specific data can't be in *any* schematic. Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? Perhaps the design should be some other data, which uses the schematic as but one of its inputs? Maybe in the backend it is a bad idiom (that is, gschem should be saving the schematic and design as separate beasts, maybe in a gzipped collection or something). But from the user's perspective it makes sense. When you first set out to design a circuit, you start by scribbling out a block-level schematic, then fleshing it out into a real schematic, long before you care about specific parts or footprints or decoupling caps. Probably these high-level schematics would be scribbled on the back of an envelope or on a whiteboard rather than in gschem, but I think it reflects a schematic-oriented view of the circuit for most people. Plus, simulations and ratsnests depend on the schematic data, so it is a sensible base for design work. -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Maybe in the backend it is a bad idiom (that is, gschem should be saving the schematic and design as separate beasts, maybe in a gzipped collection or something). But from the user's perspective it makes sense. How we organize the data, and how the user interacts with it, need not be the same :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
How we organize the data, and how the user interacts with it, need not be the same :-) I didn't read the complete threat so if I miss the point or if I repeat anyone I'm sorry. Is it not possible to make a top level program that launches the different programs (gschem, pcb, simtools, .)? The top level program can have it's own file with the meta data and cross references to the other files (the refdes maybe). The top level program can have a wizard to help new users to heavyfy the standard symbols. The top level program can have a check/lead to help setting up a simulation project/layout project/IC design project/whatever project. The top level program can call gnetlist to connect it all together. The top level program can have an import/export function to include sheets/pcb designs from other projects. This way you also have a backwards compatibility path (all additional data is stored in the TLP file), not important I know, but still... Just my €0.02 Robert. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Tue, 24 May 2011 01:34:04 -0400 DJ Delorie d...@delorie.com wrote: but I avoid name conflicts in project libraries. If we find ourselves gaining popularity and a plethora of libraries comes into being, we may no longer have the luxury of avoiding name conflict. name scoping came up a few times in the library discussion, I think keeping the issue in mind, even at time, is important. It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Of course, there would be backward-compatibility for symbols without a UUID attribute, but if a schematic made use of a symbol with a UUID, then the schematic is future-proofed against any future name collisions for that symbol. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Handling symbol change [WAS: Re: cvs.gedasymbols.org and gschem]
On Tue, 2011-05-24 at 00:41 -0700, Colin D Bennett wrote: It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Of course, there would be backward-compatibility for symbols without a UUID attribute, but if a schematic made use of a symbol with a UUID, then the schematic is future-proofed against any future name collisions for that symbol. In addition, a SHA1 hash (for example) would also ensure the tools can detect when a symbol has changed in the library - without requiring the person changing the symbol to update a version field. (An alternative would be an embedded copy of the original symbol to compare against). The embedding idea would actually work well to make schematics portable, but would lead to cluttered schematic files. If we were to move to a container based file format at any point, such copies would essentially be free (w.r.t. the level of disk space required). FWIW, I'm not a big fan of UUIDs, assigned, random or otherwise. As a silly idea - one could imagine a way of producing a this symbol replaces... field in an edited symbol which incorporates the SHA1 hash of the previous version. Perhaps the this symbol replaces field could also contain flags to specify whether the symbol is a direct compatible replacement, requires wiring changes, or whatever. The flags would define how complainy the tools got before the user acknowledged the change, e.g.: Silent change (using the new SHA1 when the user next saves the page) Informational warning Cautionary warning ...? The higher level warnings would cause gnetlist (and other tools) to abort processing unless the user can acknowledge the change. Basically I'm thinking along the lines of git revision control for symbols, or at least the log mechanism - even if the storage of previous versions isn't something we choose to do. A more complex (and not necessarily superior) solution than hashing the whole symbol file, would be to make a hash of just the important parts which affect functionality - e.g. pins and attributes. This would allow cosmetic changes not to flag the same degree of warning as functional changes. Best regards, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Is it not possible to make a top level program that launches the different programs (gschem, pcb, simtools, .)? Yes. In fact, this has been done. However, it serves to collect the various files that make up a design, not the information *in* the design. The underlying tools still deal with the same files and data as they would without a GUI, and the underying tools still force the user to jump from tool to tool to get various tasks done. What I think users want is to have the underlying tools be more aware of the other sources of data in the design, and each other, so that the GUIs appear to be more integrated despite being individual tools and datasets underneath. This may require some high-level these are the files in your design also, but it's a slightly different problem to solve. But an even different is the problem of what *design* data goes in which file. This part is not backwards compatible, because we'd want to move data out of the other files (sch, pcb, whatever) into a new container. Consider: if we have N steps in our flow, we currently have N files and N tools, each of which deals with their one data file, with converters between them. But what if each tool could interact with the data files from step N-1 and N+1 also? In the past, this has meant that gschem knew about pcb's file format, and pcb knew about gschem's (via gnetlist). But a new container between schematic and pcb (for example) would allow these two steps to have a common spot to store common data, without either needing to know about each other's private data. Now add to that, plug-ins for each tool that know how to directly communicate with other running tools related to the design (gschem, pcb, gerbv, icarus). Now, each tool has its own data and responsibilities, and *could* act in isolation, but also *could* appear to be integrated with the other tools. It would be *as if* there were one design file that all the tools knew about, when in reality there isn't one. That's the dichotomy I was referring to - how the low-level design data is stored, and how the tools interact with that data on behalf of the user. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Do you mean a UUID for a symbol template in a library, or a UUID for a specific instance of a symbol in a schematic? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
I really don't want any *major* changes to the core workflow and UI TBH. The changes that would make this a more complete tool (for me anyway) are: PCB: - better control over polygons. Ie better awareness/ability to tie to nets, built in crosshatching (intstead of solid), and an option to hide all polygons without having to put them on a separate layer (this messes with DRC) (thin draw poly is cool though!) - footprints: native text capability, polygons, manual solder-mask, manual paste mask - A manual paste layer - Not sure about how to describe this, but I think it comes under the back-annotation editing of symbols... PCB is a little thin on the ground when it comes to editing elements on the fly (can you even edit text from the gui once placed?) gschem: not too many changes as I see it... - A footprint viewer - when selecting/setting a footprint it would be nice to have a preview (this could most likely be done as some sort of plugin) - A more complete channelisation/subcircuit/bus concept - basically just tie buses and subcircuits together (i think I may try and do this myself - i've asked about it before and got some useful feedback) Light vs heavy I think this has all been said but *my* summary is * you can never have *all* the heavy symbols - and chances are most of your heavy symbols will be useful as is to less than half gEDAs users. * purely light symbols leave beginners wondering why their projects don't compile out of the box solution (as discussed) - set up a default beginner/base library with a subset of the most commonly used components (defined by how much time and effort people are prepared to put in I guess) that is shipped - don't do anything to over complicate the heavyfication process - as it stands is fine :) I think tying gschem and pcb together more closely is a separate task - DJs database. I've been thinking of attempting to do this myself for some time - i'm as far along as writing a base schema to capture the core information... A functional component can take on many forms - the alignment of function to pin and whether the function is available is interdependent with the choice of footprint, functions can be remapped amongst pins (look at most ARM chips). Ideally one should be able to define a functional requirement in the schematic, swapping which pin provides said function in the final layout shouldn't be a major chore. I don't think this is an improvement that needs to be made in gschem - gschem is for schematic capture, which it does fine. Parts/symbol/component management is a separate task, so long as gschem doesn't hinder this process great - if it can include some plugins to make the task better integrated (such as a footprint preview) even better. A tool like gschem shouldn't be tied up trying to define and handle all variations of what any given person thinks makes up a symbol. It already has the capability to have arbitrary text attributes - that's enough. Just link the gschem symbol to the database/tool (separate program) that handles the various symbol permutations via a unique ID of some description or other... Anyway - the database idea has been looked at before, and from memory even implemented somewhat; so its nothing new. Geoff (If anyone is interested in the schema I've started [1]http://nixotic.com/partsdb.png) References 1. http://nixotic.com/partsdb.png ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
DJ Delorie wrote: Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? It is not just us. it is the traditional way to look at an electronics project. Schematic, layout and BOM contain all the information needed to reproduce. Of course, the EDA may keep the data in some other form and derive these documents on the fly. But this would make the work-flow more complicated. You'd have a hard time to re-integrate a layout, once it has diverged from the schematics. This is one of the major blunders of eagle. There is no decent way to reunite layout and schematic after you changed one without the other. I have seen more than one project break this way. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 2:43 PM, DJ Delorie wrote: Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? Perhaps the design should be some other data, which uses the schematic as but one of its inputs? If you have a hierarchical design, one extra thing you need to track somehow is which schematics are at the top level, so you know which ones to feed explicitly to gnetlist. There may also be variant designs based on different but overlapping sets of schematics (my chip designs are like that). I also use pins2gsch a lot for connector maps: maintaining connectors as drawings is a pain, and not very illuminating, I think. In this case, the master is the .tsv that defines the map, not the .sch that's derived from it. I used this for the CCD driver board whose picture I posted earlier, and I'm really glad I did: the folks on the other sides of the interfaces kept changing pin assignments, and a table is much easier to fix than a drawing. So, already, for me the schematics themselves don't completely define a design, at least in my big project flows. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 3:33 PM, DJ Delorie wrote: How we organize the data, and how the user interacts with it, need not be the same :-) Please remember that what interacts with the data may not be a human user, but a script. The user behind the script must find the the organization sufficiently comprehensible that the script can be constructed to penetrate it without human help. This is exactly why GUI so commonly poisons scripting, because GUI is generally designed to facilitate human interaction, not avoid it. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On May 24, 2011, at 2:34 PM, DJ Delorie wrote: but I avoid name conflicts in project libraries. If we find ourselves gaining popularity and a plethora of libraries comes into being, we may no longer have the luxury of avoiding name conflict. name scoping came up a few times in the library discussion, I think keeping the issue in mind, even at time, is important. I agree. I was objecting to the notion that we should kill an existing function that works well in simple cases just because it could have problems in more complex cases. gEDA has a huge dynamic range in application scale, so there are going to be things that work well in some contexts but not in others. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 4:31 PM, myken wrote: How we organize the data, and how the user interacts with it, need not be the same :-) I didn't read the complete threat so if I miss the point or if I repeat anyone I'm sorry. Is it not possible to make a top level program that launches the different programs (gschem, pcb, simtools, .)? The top level program can have it's own file with the meta data and cross references to the other files (the refdes maybe). The top level program can have a wizard to help new users to heavyfy the standard symbols. The top level program can have a check/lead to help setting up a simulation project/layout project/IC design project/whatever project. The top level program can call gnetlist to connect it all together. The top level program can have an import/export function to include sheets/pcb designs from other projects. This way you also have a backwards compatibility path (all additional data is stored in the TLP file), not important I know, but still... Well, the classic TLP is make, and gEDA works pretty well with it. Of course, make is old-fashioned and rather crude. It's easy to create something prettier, but it's very hard to create something that works better. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Handling symbol change gschem]
In addition, a SHA1 hash (for example) would also ensure the tools can detect when a symbol has changed in the library - without requiring the person changing the symbol to update a version field. (An alternative would be an embedded copy of the original symbol to compare against). Note we have a similar problem in pcb, and it *does* embed symbols, and they're highly likely to be edited by the user. The embedding idea would actually work well to make schematics portable, but would lead to cluttered schematic files. I've thought about the idea of embedding the *origin* footprint in a pcb file, as a sort of project-specific embedded library, and having elements store only the deltas. This is very similar to jpd's always copy the symbol locally scheme. I haven't figured out how to merge user changes with library changes, though. FWIW, I'm not a big fan of UUIDs, assigned, random or otherwise. We need a way to uniquely identify, say, different gates in the same package in a schematic. Consider a sheet with three NAND gates, both U4. How do you tell which is which when you want to swap gates across physical packages in the layout? Since the swap changes the refdes, you can't rely on the refdes as a unique identifier any more. Worse is when you want to have one package provide gates for different sub-circuits in a heirarchy - the instances of the gates refer to the *same* symbol! Now what? Now we need not only a UUID for the symbol on the sheet, but for the path to the symbol in the design as well. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
I really don't want any *major* changes to the core workflow and UI TBH. Understood. The changes that would make this a more complete tool (for me anyway) are: Yup, all discussed before. One impossible task at a time please :-) (can you even edit text from the gui once placed?) the 'n' key (change Name, originally for refdes, but now for any text) I think this has all been said but *my* summary is Yes, I think your summary aligns with what we discussed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
It is not just us. it is the traditional way to look at an electronics project. Schematic, layout and BOM contain all the information needed to reproduce. We currently derive the BOM from other sources (well, from the schematics). PCB can derive its own BOM as well. The metadata idea would flip this, and have the BOM be an *input* to the process, not an *output*. This is one of the major blunders of eagle. There is no decent way to reunite layout and schematic after you changed one without the other. I have seen more than one project break this way. Yeah, that was a tough problem to solve, until I realized (well, considered :) that the layout-specific data does NOT need to be reunited with the schematics. The key problem is, if you have conflicting information in two places, which is correct? My though was: if it's layout-specific data, the copy in the layout is correct. Perhaps we need to keep track of whether the data in the layout and schematic originated in that file, or is the result of user changes elsewhere being imported. But any solution depends on (1) allowing data to originate from multiple places, and (2) sane rules for which wins. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Pin numbers are a bit harder than most other attributes in the present state of gnetlist, because the front end employs pin numbers internally to track pin identity. Yup. I had proposed using the pin *label* as the identifier, not the pin *number*. The label is owned by the schematic, but the number is owned by the partdb or layout. That lets you, for example, change the package in layout without having to change the schematics first. And, of course, there's no reason that the rules need to come from a single place, using a uniform format. I hadn't gotten around to thinking about where the rules came from, just that they should exist. I suspect any solution would need to be available to gschem and pcb also (or anything else), though, for previews and manual changes. I did think about where the *metadata* would come from, and some API to hide all that behind. I'm waffling between something like HTTP/CGI (automatic integration with any web server) or SQL (powerful query language). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Please remember that what interacts with the data may not be a human user, but a script. The user behind the script must find the the organization sufficiently comprehensible that the script can be constructed to penetrate it without human help. This is exactly why GUI so commonly poisons scripting, because GUI is generally designed to facilitate human interaction, not avoid it. My flows are also heavily scripted, so yes, I'll remember. The underlying data and low-level tools follow the scripting paradigm - stepwise progress from A to Z via simple apps that interact with simple data. The GUI needs to *hide* that, not replace it, making the underlying data *seem* integrated and easy to manage, when in fact it is not. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Tue, 2011-05-24 at 15:24 +0900, John Doty wrote: On May 24, 2011, at 2:43 PM, DJ Delorie wrote: I also use pins2gsch a lot for connector maps: maintaining connectors as drawings is a pain, and not very illuminating, I think. In this case, the master is the .tsv that defines the map, not the .sch that's derived from it. I used this for the CCD driver board whose picture I posted earlier, and I'm really glad I did: the folks on the other sides of the interfaces kept changing pin assignments, and a table is much easier to fix than a drawing. So, already, for me the schematics themselves don't completely define a design, at least in my big project flows. It has been my wish for some time that a netlist / BOM type input file becomes more first class within gEDA. Net lists / BOM are the about the most fundamental piece of data within an EDA tool. Schematics are just one way of inputting that, and PCB layouts are just one way of embodying it. It seems un-warranted to make a schematic file from a data-table when the end output is just the data-table in a different format. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On Tue, 2011-05-24 at 16:56 +0900, John Doty wrote: Well, the classic TLP is make, and gEDA works pretty well with it. Of course, make is old-fashioned and rather crude. It's easy to create something prettier, but it's very hard to create something that works better. make is a clever tool, and underlying its operation is constructing a directed dependency graph, then computing an operation order to satisfy the desired target(s). I would love to see the data-structure and algorithmic part of make made available as a library so we could build upon those parts more readily, or perhaps even wrap a GUI around a real Makefile and show the user a graphical representation of the project state. Details of the Makefile syntax and the fact that actions are made from shell script fragments is somewhat irrelevant. The underlying logic is re-implemented in many projects in quite diverse areas. Inkscape import filters and gstreamer pipelines are two examples I can think of right now. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
What I think users want is to have the underlying tools be more aware of the other sources of data in the design, and each other, so that the GUIs appear to be more integrated despite being individual tools and datasets underneath. This may require some high-level these are the files in your design also, but it's a slightly different problem to solve. So if I understand correctly each program in the gEDA tool chain will need a pipe/gate/threat/port/whatever through which it can communicate to a TLP or the N-1 and N+1 tool in the work flow. Something like a multi master serial communication link (I'm more a hardware engineer than a software engineer ;-) But an even different is the problem of what *design* data goes in which file. This part is not backwards compatible, because we'd want to move data out of the other files (sch, pcb, whatever) into a new container. This shouldn't be a problem, the file format of gschem is an excellent example of flexibility. If you have a TLP which can gather information from the various files and make a new file with the meta data it didn't find then your OK. For the user it doesn't matter where the information is stored as long as it is stored. For a script or a text-file junkie it might be hell. Or am I missing something? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: cvs.gedasymbols.org and gschem
On Tue, 24 May 2011 07:57:28 -0400 DJ Delorie d...@delorie.com wrote: It might be useful to include a UUID in symbols so that once a particular symbol is in use, the identity of that symbol can be guaranteed through a UUID reference. Do you mean a UUID for a symbol template in a library, or a UUID for a specific instance of a symbol in a schematic? My initial thought was for an abstract symbol (i.e., a .sym file). This way Diode.sym from my personal library is treated as a unique symbol from Diode.sym from another library. But now that you mention it, a UUID for a symbol instance in a schematic is important too, particularly when slots come into play. Proper design of the slotting system would fix the footprint for a slotted symbol is taken only from the first instance with that refdes problem... Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Lot of good discussion here. Keep it up. I work in the asic/fpga arena and I am building a tool flow based on the ip-xact standard (IEEE-1685). It has a lot in it that solves many of the problems in this discussion and I would suggest that gEDA might want to borrow a few tips from that standard. 1) It is targeted for exchanging data between tools. All the files use xml so that parsers are available for all languages. 2) All objects have a unique identifier. Ip-xact uses a VLNV for Vendor,library,component and version. There are no name collision issues as long as the rules are followed. 3) Multiple views are supported. I can created a view with one deliverable for simulation and a different view and deliverable for synthesis. I can generate a light symbol view as well as a heavy one. 4) No problems with data duplication. By using correct by construction techniques you never duplicate data. You keep the master source in an ip-xact file and generate everything from there. 5) Overlays are supported. You never modify anything that you do not have engineering responsibility for. If you want to change a library part for a local design then you create a local part that uses the lib part and then all the changes are made in the local part. The master is never touched. 6) ComponentGenerators are supported. You can embed generators inside of a component that control how it is processed by other tools. John Eaton ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
I have not been following this closely, so let me make a guess at what the basics are, and in so doing through my little 2 kopecks worth in. If there were a combined, heavy library with both circuit element symbols and footprints contained within a single grouping for a single device, part number, group of related parts, so that from either gschem or pcb you could search for the root name of that part/device and be given a list of possible symbols to use in gschem (I know Atmel Atmega parts have differing numbers of pins based on DIP, TSOP, etc) and then the matching footprint (or footprints, if several package/mounting styles or sizes could still fit) would be stuffed into the element attributes. Or, if you were working directly in pcb, you would access the same library, search for the same root device name, and be given a list of all known footprints for it ( and possibly stuff the corresponding symbol in the element attributes incase you ever wanted to go backwards to gschem). This group, bundle, set of data might also include spice model data for the part (possibly once again linked to a package style). In either case, you could open up the linked data in either gschem or pcb to 'heavy up' the item you are working on to export the data to some other tool flow (does pcb to spice to verify the design make sense?) As for names, data pack would be similar industry standard data sheets. Technically, these would be data nodes or data branches or data clusters. You could even call them device seeds because they seed desired data into whatever tool path they have data for and you desire. Mike ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 9:37 PM, DJ Delorie wrote: I had proposed using the pin *label* as the identifier, not the pin *number*. The label is owned by the schematic, but the number is owned by the partdb or layout. That lets you, for example, change the package in layout without having to change the schematics first. What about packages with duplicate pins, e.g. both 2 and 4 are drain? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 9:43 PM, DJ Delorie wrote: My flows are also heavily scripted, so yes, I'll remember. The underlying data and low-level tools follow the scripting paradigm - stepwise progress from A to Z via simple apps that interact with simple data. The GUI needs to *hide* that, not replace it, making the underlying data *seem* integrated and easy to manage, when in fact it is not. This is where we disagree. The GUI needs to make the data easy to manage, but at the same time it needs to *reveal* its machinations. If it hides everything, the user winds up either: 1. stuck with the GUI, unable to use the toolkit as a kit, or 2. having to penetrate the GUI code to figure out how to use the kit. It's like having a travel agent book a trip: you might say I want to get from A to B, but the itinerary the agent delivers had better reveal the route. And that route had better be simple enough that you can understand it. That one can hide complexity behind an interface does not excuse unnecessary complexity. When SUN created GUI for system administration, a sysadmin friend of mine complained bitterly that the result was they used it as a license to expand the admin databases in an undisciplined way, because the GUI could hide the chaos. But if you need to script admin tasks... Back in the early days of NeXT, their GUI-building GUI, Interface Builder, was really easy to use. It emitted the Objective-C code to construct and connect the objects behind the interface, so it was easy to understand what was going on behind the scenes. That's important. While the GUI is very useful to get the appearance right, the functionality requires actual coding. But they couldn't leave a good thing alone. Programmers are supposed to hide information regardless of its importance to the user these days, so they fixed IB to directly and invisibly create archived objects in a fully initialized state. The result was that what had been clear became mysterious, and you had to be much more of an expert to get results. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
What about packages with duplicate pins, e.g. both 2 and 4 are drain? PCB already handles this by just treating them as one pin with two copper bits, but you could use D1/D2 if you wanted to make them separate. But I did cover this in my pin mapping doc: Here's the 8-SOIC case, showing how to map a single schematic pin to multiple footprint pins: G = 4 S = [1,2,3] D = [5,6,7,8] ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
I think what a GUI does is no different than what Make does - it lets you encapsulate complex operations into simpler ones. When a user clicks on run simulation, they don't care how many steps it takes to do that, they just want their simulation. When you run make sim to run your simulation, you don't care what the Makefile does, only that it does it. With that point of view, look at your argument wrt your flow: This is where we disagree. The Makefile needs to make the data easy to manage, but at the same time it needs to *reveal* its machinations. If it hides everything, the user winds up either: 1. stuck with the Makefile, unable to use the toolkit as a kit, or 2. having to penetrate the Makefile code to figure out how to use the kit. (er, as an example, I still don't know how to rebuild just one subdirectory of the Linux Kernel - I always run a full make from the top, because that's the only thing I've figured out so far) The solution to these problems is not transparent tools, it's better documentation. I've seen the Makefiles ISE spits out, that doesn't tell me how the tools work. Now, I don't think the GUI should hide information for the sake of being obscure. I think the GUI should hide information because the user already has enough to worry about. We get a lot of users complaining about too many clicks or why can't I do that in the gui. They use a GUI because they want to work on their design, not learn how to use our tools. Many of them don't even know a shell window exists. Consider the pcbfwd netlister (File-Import in PCB). It's scriptable. You could run gnetlist manually. You can use that in a Makefile to update a layout. But the *only* feedback (er, non-bug-report type) I get about it is Wow! I can update my layout with one button!. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
Mike Bushroe mbush...@gmail.com writes: As for names, data pack I like data pack. But the seed idea is growing on me too. (sorry, couldn't resist ;) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 9:37 PM, DJ Delorie wrote: I did think about where the *metadata* would come from, and some API to hide all that behind. I'm waffling between something like HTTP/CGI (automatic integration with any web server) or SQL (powerful query language) I think if we continue to worry about what the user or consumer might see without prototyping it, we'll just argue about it forever. But we seem to have reached the consensus that gnetlist is the place where everything should come together. That, I think, requires refactoring gnetlist. When the right factors are present, the gnetlist approach is very powerful, but we don't have all of them here. We can't really make a prototype that covers the ground. I'm quite willing to help on the plug-in/back-end side, but working on a minor refactoring of gnetlist itself was a very negative experience. I have no desire to descend into the Mines of Moria again. Who is brave enough? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 25, 2011, at 5:58 AM, DJ Delorie wrote: I think what a GUI does is no different than what Make does - it lets you encapsulate complex operations into simpler ones. When a user clicks on run simulation, they don't care how many steps it takes to do that, they just want their simulation. When you run make sim to run your simulation, you don't care what the Makefile does, only that it does it. Sometimes yes, sometimes no. I often use make -n or look at the rules in the makefile. One problem juggling many long term projects is that I forget how I organized the processes years ago when I set things up. That's part of the power of make: it can hide or reveal as needed. The solution to these problems is not transparent tools, it's better documentation. Sure. That's easy to say, very difficult to implement. I've seen the Makefiles ISE spits out, that doesn't tell me how the tools work. Bad factoring is always a problem. Now, I don't think the GUI should hide information for the sake of being obscure. I think the GUI should hide information because the user already has enough to worry about. We get a lot of users complaining about too many clicks or why can't I do that in the gui. They use a GUI because they want to work on their design, not learn how to use our tools. Many of them don't even know a shell window exists. They don't automate. There's a place for that. But what makes gED*A* *uniquely* powerful is its friendliness to automation. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On May 24, 2011, at 10:30 PM, Peter Clifton wrote: the fact that actions are made from shell script fragments is somewhat irrelevant. I think it's highly relevant, because it means that anyone familiar with shell commands has a head start understanding what's going on. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
