Re: gEDA-user: Soft and Hard symbols
On Jan 19, 2011, at 10:31 AM, Peter Clifton wrote: Consider my opinion on the matter changed though, as I've heard some vaguely convincing use-cases. I did think that stating that the issue doesn't matter to me was somewhat unfair though. It does. I am sorry you feel it was unfair. Consider the ratio of the circumference of a circle to its diameter in Euclidean geometry. Classically, that's the definition of Pi. Now square the integral of exp(-x^2) from negative infinity to positive infinity. The result is identical to Pi. But wait! There are no circles present in the second problem! So that can't be Pi, it must be something else! That's not a use case for Pi that anyone could anticipate, so nobody should be allowed to use Pi in this way. It doesn't fit the definition. Fortunately, mathematicians and scientists are more open minded than that: they realize that powerful concepts take on a life of their own, and find many use cases far afield from their original intent. The same is true of software. Tools are generally conceived for particular use cases, but a truly excellent tool transcends those and goes far beyond the original intent of its designer. But if someone places unnatural restrictions on what the tool is allowed to do simply because they cannot conceive of a use case beyond some arbitrary boundary, the excellence of the tool will be abridged. One of the reasons I admire the Bell Labs pioneers so much is that they really understood this basic principle of software excellence. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business go along to get along causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Tue, Jan 18, 2011 at 2:05 AM, Peter Clifton pc...@cam.ac.uk wrote: Connectivity is precisely the kind of thing that should not be in libgeda. I (and all other gEDA developers I've talked to) disagree. That's interesting. Many of my issues with gschem and gnetlist are at some level related to low level of abstraction provided by libgeda. What people expect from EDA tools is not a pretty drawing (that's what they use PowerPoint for), they want these tools to assist them in the design and maintenance process, freeing them from remembering everything and perhaps catch some errrors. This assumes that the tool has some knowledge of the application it is used for. Sure, it is impossible to design a perfect tool (that would mean the designer is no longer needed), but more the tool knows, the better. This is the first time I hear that gEDA developers are even considering changes in this area (or was it simply because of closing down the geda-dev mailing list?). If that indeed is the case, I could do some work on the project without having a feeling of lost effort. The question is, how far would you like gEDA to go in this direction? IMHO this should go rather far (you know, others were doing it for decades). Libgeda (or, what I'd like to call it, the database) should be _the_ way of accessing and interpreting the design data, perhaps even doing some IPC so that different program instances, each linking to libgeda are aware of each other. An open, documented backend (file format) is still valuable as a fallback option (for quick scripting jobs that do not need full knowledge of the design connectivity etc.). The latter option + open API is what distinguishes gEDA from commercial guys - they, in addition to all the engineering purposes, tend to use the database as a lock-in tool. Andrzej ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 19, 2011, at 7:14 PM, Andrzej wrote: Sure, it is impossible to design a perfect tool (that would mean the designer is no longer needed), but more the tool knows, the better. But gEDA isn't a tool: it's a toolkit. In a toolkit, you maximize power and flexibility by having the tools specialize. The less a tool knows about stuff outside its specialty, the more powerful and flexible it can be within its specialty. 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: Soft and Hard symbols
But gEDA isn't a tool: it's a toolkit. I consider gEDA to be a tool. gschem, gattrib, gnetlist - all tools. Thier job is to help engineers automate the design process, to do that, they have to know a lot about electronics design. The less a tool knows about . . . You just said it wasn't a tool. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Dj you own a tool box, I've seen you build mechanical things. gEDA is a toolkit (toolbox), with your logic gnu unix is a tool. If I want to clean up the cylinder an engine block I get out an engine block hone, I do not get out a wire brush. Now in gEDA terms. When you want to edit a schematic, you break out gschem, and when you want bulk changes to attributes you get out gattrib. and when you doing something crazy you make a new tool, say in your favorite language for the job. 100% agreement with John; gEDA is a toolkit, not a single tool. being through, Kit: 1. A set of articles or equipment needed for a specific purpose : a first-aid kit. Not the computer science meaning of toolkit like GTK. Steve On Wed, Jan 19, 2011 at 6:08 AM, DJ Delorie d...@delorie.com wrote: But gEDA isn't a tool: it's a toolkit. I consider gEDA to be a tool. gschem, gattrib, gnetlist - all tools. Thier job is to help engineers automate the design process, to do that, they have to know a lot about electronics design. The less a tool knows about . . . You just said it wasn't a tool. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
gEDA is a toolkit (toolbox), with your logic gnu unix is a tool. gEDA is more like a design suite, a collection of tools and related stuff. Not the computer science meaning of toolkit like GTK. We're doing computer science, we have to use the CS meanings of things. A toolkit in CS is primarily a library. gEDA is more than just a library. Would you call OpenOffice a toolkit? It has a library. What about Firefox? It has a library. gEDA? It has a library. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 19, 2011, at 12:10 PM, DJ Delorie [1]d...@delorie.com wrote: gEDA is a toolkit (toolbox), with your logic gnu unix is a tool. gEDA is more like a design suite, a collection of tools and related stuff. And before you said it was a tool. Not the computer science meaning of toolkit like GTK. We're doing computer science, we have to use the CS meanings of things. A toolkit in CS is primarily a library. Not quite, a library is a component of a toolkit, but there are many other components of a toolkit. Taking qt as an example. There is the ui designer application, the core libraries, and documentation. Naming the few top level components. gEDA is more than just a library. See above, a toolkit is much more than just a library. Would you call libpng a toolkit? No it is a library. Would you call OpenOffice a toolkit? No, it produces documents that are largely independent. Each application stands on it's own. It has a library. What about Firefox? A single application. It has a library. gEDA? It has a library. And a few other libraries (libgeda, symbols, scheme, ...) Assistant applications that manage those libraries to design circuits. Gschem, gattrib, xgschem2pcb, djboxsym, and many others. Documentation like your excellent tutorials for pcb. Guides on how to do simulation. Just because we are not compiling c code, does not mean that we are not a toolkit. I have now determined that my original statement that not in a computer science meaning is wrong, gEDA meets the compsci meaning of toolkit very nicely. The argument you are using to decrease the value of John's opinion is purely based on semantics. Our users could not care less about the term toolkit verses tool suite vs many applications in a folder. The gEDA developers are doing computer science but our users are not. The gimp toolkit allows it's users to make gimp like applications, the geda toolkit allows it's users to make electronic designs. It's all semantics and context. But in John's defense if geda was treated just as a tool ( note the singular unified meaning of tool ). Then a huge portion of flexibility is lost. And it would become as limited as many of the other tools out there. Such as eagle, kicad, or, other printed circuit design tools. I have seen this in many different projects and designs. An I work at a company with arguably the cream of the crop user interface and user experience designers, Apple. Yet we often drive away power users because things were made too simple, for one flow. Steve ___ geda-user mailing list [2]geda-user@moria.seul.org [3]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. mailto:geda-user@moria.seul.org 3. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
And before you said it was a tool. It is a tool, and more like a design suite than a toolkit. If you're going to play with words just to make your argument, I'm leaving. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 19, 2011, at 11:08 PM, DJ Delorie wrote: But gEDA isn't a tool: it's a toolkit. I consider gEDA to be a tool. gschem, gattrib, gnetlist - all tools. gschem, gattrib, gnetlist are tools. gEDA is a toolkit. Thier job is to help engineers automate the design process, to do that, they have to know a lot about electronics design. Collectively, yes. Separately, no tool needs to know more than its specialty. That's modular, factored design. The less a tool knows about . . . You just said it wasn't a tool. The toolkit is composed of tools. The tools are specialists, the kit isn't so much. 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: Soft and Hard symbols
On Jan 20, 2011, at 5:10 AM, DJ Delorie wrote: gEDA is a toolkit (toolbox), with your logic gnu unix is a tool. gEDA is more like a design suite, a collection of tools and related stuff. Not the computer science meaning of toolkit like GTK. We're doing computer science, we have to use the CS meanings of things. A toolkit in CS is primarily a library. Did you ever read Software Tools by Kernighan and Plauger? Absolutely brilliant book on software engineering, dated only in the fact that they were using FORTRAN as their foundation. Their tools were separate utility programs. That's the sense I mean. gEDA is more than just a library. Would you call OpenOffice a toolkit? It has a library. What about Firefox? It has a library. gEDA? It has a library. gEDA fundamentally has a file format. You don't have to use the library, and many of the simpler gEDA tools, e.g. djboxsym, don't use the library. 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: Soft and Hard symbols
On Fri, 2011-01-14 at 21:14 -0500, al davis wrote: I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. On Saturday 15 January 2011, Peter Clifton wrote: Not done. Would be nice though - but I'd rate it of similar complexity to a board auto-router. (Not as rigidly constrained topologically, but to do well would require a decent auto-place, and a decent auto-router - even if the rules are different to that used with a PCB). Ah .. but I said and rendering info. Generating a schematic from a netlist without the rendering info, you are absolutely correct. But that's where the rendering info comes in. It tells where to place and route in a portable way. Where does the rendering info come from? Mostly, it would be saved when you convert a schematic to a netlist. That way it is available when you convert it back, so when you make a round trip you get the same schematic you had before. Or, if you made some changes in the netlist you get the schematic with the changes. You might need to move the new stuff for looks, but it would at least be functional. Or, convert one kind of schematic, saving the rendering info in a portable way, and write it out as another kind of schematic. That's the translation facility. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Peter Clifton pc...@cam.ac.uk writes: On Tue, 2011-01-18 at 16:05 +0900, John Doty wrote: Note that there's a bit of terminology confusion. gschem actually manipulates segments of nets (other tools sometimes call these wires), while net in EE theory is usually a topological whole, where the connection is assumed to be structureless. wires is a useful distinction here, although it sounds like it implies something physical. I'll try to call them net segments from now on. Sometimes a gnetlist backend might wish to request the connectivity of a net (the topological whole). IMO libgeda should be able to provide that. (A library or convenience function if you will). It does not happen very often, but in this point my opinion disagrees with John's, I think. The whole point of libgeda and gnetlist is to express connectivity between pins. Machine-interpreting meaning into the details of the individual net segments is a confusing concept, that should not be encouraged by the tools. If such things need to be expressed, I'd introduce a new type of symbol, and teach the gnetlist backend that needs those semantics to treat both/all connections to that symbol as the same net, but with different attributes. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Hi John, Constructive comments below, but first I thought I'd get this out of the way.. From my point of view, you often seem to treat people here with a less respect than they deserve. I get the impression you think of the gEDA developers as being ignorant, blinkered, or incapable directing the future design and architecture of the suite. You also persist in repeating the same design choices you have chosen to make as the panacea for everyone else's work. I really hope this can stop. Your input has proved valuable on many occasions, and it would be useful for us to gain from your insight rather than develop the predilection to dismiss your emails as yet another rant from JPD. I already find myself having to skip them over for later reading, as they often disrupt a thread's natural flow. Your humorous email sign off suggests that you are aware of the problem, but not willing to adjust the courtesy of your replies. We are smart enough to understand a well reasoned design trade-off, and would likely respond better to that than yet another proclamation of why what we have suggested is wrong, or inadequate. I'll humour you with a reply below.. On Mon, 2011-01-17 at 05:31 +0900, John Doty wrote: On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: I want to see all connectivity code move into libgeda, and flattening be optional. Connectivity is precisely the kind of thing that should not be in libgeda. I (and all other gEDA developers I've talked to) disagree. The connectivity model depends on the application of the schematic. Not really, it just depends on whether we are talking about the same thing. I suspect not. I was not thinking of of assigning the data-type (for want of a better word) of nets, width, whatever. gschem can front schematic entry for various flow based or signal based topological connectivities, where nets might report block interconnections, mathematical relations, pipe-work, whatever. In all these cases, the useful output from libgeda / gschem is the topology / connectivity of the instantiated modules / symbols. The model I was assuming was that the exact topology of nets in gschem is unimportant. It is a common model, but my proposal of handling connectivity in libgeda doesn't _require_ that assumption if it is unwanted. Right now, gEDA basically only supports a topological model. This prevents it from expressing most geometric properties of the connections: parasitic inductances and resistances, high current net segments, single point grounds, etc. A related limitation that some wish to relieve is the fact that busses are mere graphical decoration. One could still wish to query libgeda for a connectivity list or graph for a given design. IMO, it is silly to pretend that nets should be treated as components with parasitic inductance or resistance. For that to be meaningful, one would have to match the topology of one's schematic to the physical layout they wished to simulate. Even with that said, the idea warms to me slightly - and I still cannot see how connectivity in libgeda conflicts with your suggestion. Granted, each junction node would have to be treated explicitly in the graph.. and nets themselves would have to become component entities in the list, rather than flattened - but it is still completely possible. In effect, you look on a view where a net in gschem becomes a two ported component with properties, a peer to other symbols representing components such as resistor, n-mos FET, etc. _Connectivity_ still exists, and libgeda could usefully contain routines to extract that. There cannot be a single correct way to address these issues because the appropriate connectivity model depends on the capabilities of other tools in the flow, not just gschem/gnetlist, as well as the needs of the project. I don't see anything which can't be handled as above. There are other places where the core code implements semantics that are useful in common cases but not universal. Gah, yes - The best example I can think of is that I'd love to get rid of slotting from the core. (Along with all the pinseq nastiness). I've taken steps to put that code at arms length from the rest of libgeda and gschem, so it is not so interwoven with the rest of the suite. I assume you won't have noticed that though, especially because the majority of the changes are in my repo.or.cz branches (it has other issues needing fixing before it can merge). Consider for a moment a dual opamp [snip] I'm familiar with the problem. Now consider hierarchy... [snip] I'm familiar with the problem. It would be very useful to have better standards for the intended meaning of the various attributes, but that won't help the problem of writing universal code to interpret them. The translation to pcb, SPICE, BOM, etc. will remain target and project dependent. Helper functions for common cases are very desirable, but they must not be wired-in to the core code. Better standards
Re: gEDA-user: Soft and Hard symbols
On Jan 18, 2011, at 2:05 AM, Peter Clifton wrote: Hi John, Constructive comments below, but first I thought I'd get this out of the way.. From my point of view, you often seem to treat people here with a less respect than they deserve. I get the impression you think of the gEDA developers as being ignorant, blinkered, or incapable directing the future design and architecture of the suite. You also persist in repeating the same design choices you have chosen to make as the panacea for everyone else's work. I really hope this can stop. Your input has proved valuable on many occasions, and it would be useful for us to gain from your insight rather than develop the predilection to dismiss your emails as yet another rant from JPD. I already find myself having to skip them over for later reading, as they often disrupt a thread's natural flow. If I was thin skinned, I would be insulted by the above. Your humorous email sign off suggests that you are aware of the problem, but not willing to adjust the courtesy of your replies. Weird. You find it humorous? It's not a joke. We are smart enough to understand a well reasoned design trade-off, and would likely respond better to that than yet another proclamation of why what we have suggested is wrong, or inadequate. I'll humour you with a reply below.. On Mon, 2011-01-17 at 05:31 +0900, John Doty wrote: On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: I want to see all connectivity code move into libgeda, and flattening be optional. Connectivity is precisely the kind of thing that should not be in libgeda. I (and all other gEDA developers I've talked to) disagree. As a developer of gnetlist back ends, I am frustrated by the way the core code hides critical information. Bas Gjeltes and I developed a partial fix for one of the many problems here. Patrick and Peter B. garbled it and turned it into something that doesn't actually deliver the fix to the end user. At least now I can write a plug-in that fixes it for my flows, publish on gedasymbols, but ordinary users will still trip over it. At the same time, the API available to a gnetlist back end can often make export to printed circuit layout a breeze. This tells me that the existing API is good, but it should be helpers atop the lower level, not primitive. The connectivity model depends on the application of the schematic. Not really, it just depends on whether we are talking about the same thing. I suspect not. I was not thinking of of assigning the data-type (for want of a better word) of nets, width, whatever. Note that there's a bit of terminology confusion. gschem actually manipulates segments of nets (other tools sometimes call these wires), while net in EE theory is usually a topological whole, where the connection is assumed to be structureless. gschem can front schematic entry for various flow based or signal based topological connectivities, where nets might report block interconnections, mathematical relations, pipe-work, whatever. In all these cases, the useful output from libgeda / gschem is the topology / connectivity of the instantiated modules / symbols. Mere topological connectivity can't express the (very common) need for certain wires within a net to be short, others to be thick, others to match the length of a different wire, single-point grounds, etc. The model I was assuming was that the exact topology of nets in gschem is unimportant. It is a common model, but my proposal of handling connectivity in libgeda doesn't _require_ that assumption if it is unwanted. Right now, gEDA basically only supports a topological model. This prevents it from expressing most geometric properties of the connections: parasitic inductances and resistances, high current net segments, single point grounds, etc. A related limitation that some wish to relieve is the fact that busses are mere graphical decoration. One could still wish to query libgeda for a connectivity list or graph for a given design. You mean a graph of wire and pin connectivity corresponding to a given net? That's more primitive than a list of pins associated topologically with a net. But it still wouldn't let someone write a plug-in for bus connectivity, for example. IMO, it is silly to pretend that nets should be treated as components with parasitic inductance or resistance. For that to be meaningful, one would have to match the topology of one's schematic to the physical layout they wished to simulate. You're confusing topology with geometry. A bunch of wires connected together without loops are topologically just a lump of metal. But gschem can schematically represent geometry. And I'd like to do that. Indeed, when I draw a net whose segments have geometric constraints, I try to imitate those constraints, and put in a note to the layout person about this. But it would be nice to be able to pass this information to
Re: gEDA-user: Soft and Hard symbols
On Jan 15, 2011, at 1:42 AM, Peter Clifton wrote: I want to see all connectivity code move into libgeda, and flattening be optional. Connectivity is precisely the kind of thing that should not be in libgeda. The connectivity model depends on the application of the schematic. Right now, gEDA basically only supports a topological model. This prevents it from expressing most geometric properties of the connections: parasitic inductances and resistances, high current net segments, single point grounds, etc. A related limitation that some wish to relieve is the fact that busses are mere graphical decoration. There cannot be a single correct way to address these issues because the appropriate connectivity model depends on the capabilities of other tools in the flow, not just gschem/gnetlist, as well as the needs of the project. There are other places where the core code implements semantics that are useful in common cases but not universal. Consider for a moment a dual opamp. Manufacturers' SPICE models for these are conventionally coded for a single device. Therefore, if you're going to simulate with SPICE, it makes sense to use a slotted symbol, but treat the slots as separate devices. On the other hand, in printed circuit layout it's a single device. The semantics of slotting therefore differ beween flows. The tools must not assume either semantic model is universally correct. The fact that the semantics here are in the libgeda core is a barrier to making schematics that can be input to both simulation and layout. Now consider hierarchy. Some circuit representations (like pcb) are flat, others (like SPICE) are hierarchical. Right now, we use incompatable circuit descriptions to express these: we cannot create a pcb netlist from hierarchical SPICE schematics. The problem goes beyond simply turning flattening on and off. It would be very useful to have better standards for the intended meaning of the various attributes, but that won't help the problem of writing universal code to interpret them. The translation to pcb, SPICE, BOM, etc. will remain target and project dependent. Helper functions for common cases are very desirable, but they must not be wired-in to the core code. Better standards could lead to better helpers, though. A similar situation exists with busses, where we'd like to make the graphics meaningful, but still face the problem of implementing that meaning downstream using a variety of tools in a variety of flows. The common theme is that the core code in libgeda, gschem, and gnetlist implements semantics that one might think are universal, but in fact differ among different flows. The existing semantics are excellent for creating designs that are exportable to a wide variety of printed circuit layout back ends. They are also good for simulation schematics, ASIC schematics, and symbolic circuit analysis (but nonportably: these schematics must be constructed specifically for the downstream tool). This is a spectacular achievement, but these same semantics block expansion of capability and extension of portability of schematics because they are wired-in, difficult to bypass when they aren't appropriate. Stephan's diagnosis and suggested treatment in http://www.seul.org/pipermail/geda-user/2010-December/051273.html are spot-on. The API functions that deliver the results of connectivity, slotting, hierarchy expansion, etc. are not sensibly primitive: they are library functions to be called when appropriate and ignored when not. The real primitives are at a lower level. 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: Soft and Hard symbols
On Fri, 2011-01-14 at 21:14 -0500, al davis wrote: Reading a file is easy. The hard part about the geda format, where use of libgeda may be advantageous, is establishing connectivity. A mix of libgeda, with gnetlist wading in and flattening things (perhaps unhelpfully). I want to see all connectivity code move into libgeda, and flattening be optional. I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. Not done. Would be nice though - but I'd rate it of similar complexity to a board auto-router. (Not as rigidly constrained topologically, but to do well would require a decent auto-place, and a decent auto-router - even if the rules are different to that used with a PCB). -- 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) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Peter Clifton pc...@cam.ac.uk writes: On Fri, 2011-01-14 at 21:14 -0500, al davis wrote: Reading a file is easy. The hard part about the geda format, where use of libgeda may be advantageous, is establishing connectivity. A mix of libgeda, with gnetlist wading in and flattening things (perhaps unhelpfully). I want to see all connectivity code move into libgeda, and flattening be optional. I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. Not done. Would be nice though - but I'd rate it of similar complexity to a board auto-router. (Not as rigidly constrained topologically, but to do well would require a decent auto-place, and a decent auto-router - even if the rules are different to that used with a PCB). Why would anybody want such a schematic? I see two semi-graphical ways to express a netlist in gschem format. 1. Each element uses the same generic symbol, with the proper attributes attached, and net= attributes for connectivity. Placed on some grid in arbitrary order, optionally so that the attribute lists do not overlap when viewed graphically. 2. When symbols are available for the elements, those can be placed on some grid, and each pin gets a little net stub with netname= for connectivity. Last millenium, some cadence netlister move such schematics from synthesized Verilog netlist, but I do not remember why they were needed in the flow, certainly not for human inspection. A mixture between 1. and 2., in case there is some way to feed an element to symbol map into the process, falling back to 1. for elements without symbols. But that use case is What are the use-cases? Mix gschem schematics with synthesis output into gnetlist for ASIC or simulation targets? -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Sat, 2011-01-15 at 13:10 +0100, Stephan Boettcher wrote: What are the use-cases? IMO, only viewing of synthesis results, or matching up / creating a schematic which matches an extracted netlist - either from reverse engineering, layout extraction, or from another program. -- 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) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Thu, 2011-01-13 at 19:41 -0500, al davis wrote: On Jan 12, 2011, at 11:29 AM, al davis wrote: That's great. There is a long list of things that need to be done. Where do you want to start? My preference is to start with netlist translation, using gnucap's translator system that goes both ways. In this case, that's a language plugin, reading and writing the gschem format Ideally (to be forward compatible with format changes), that plugin would use libgeda. If someone starts on this, please let us know via the lists + bug tracker ( https://launchpad.net/geda/+bugs ) if you find any API which is lacking. then another language plugin for the PCB format. I don't see how the two are congruent. Did you mean for extracting layout for simulation? -- 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) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Friday 14 January 2011, Peter Clifton wrote: On Thu, 2011-01-13 at 19:41 -0500, al davis wrote: On Jan 12, 2011, at 11:29 AM, al davis wrote: That's great. There is a long list of things that need to be done. Where do you want to start? My preference is to start with netlist translation, using gnucap's translator system that goes both ways. In this case, that's a language plugin, reading and writing the gschem format Ideally (to be forward compatible with format changes), that plugin would use libgeda. If someone starts on this, please let us know via the lists + bug tracker ( https://launchpad.net/geda/+bugs ) if you find any API which is lacking. That makes sense to me, I think. then another language plugin for the PCB format. I don't see how the two are congruent. Did you mean for extracting layout for simulation? Yes. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 14, 2011, at 6:32 AM, Peter Clifton wrote: On Thu, 2011-01-13 at 19:41 -0500, al davis wrote: On Jan 12, 2011, at 11:29 AM, al davis wrote: That's great. There is a long list of things that need to be done. Where do you want to start? My preference is to start with netlist translation, using gnucap's translator system that goes both ways. In this case, that's a language plugin, reading and writing the gschem format Ideally (to be forward compatible with format changes), that plugin would use libgeda. If someone starts on this, please let us know via the lists + bug tracker ( https://launchpad.net/geda/+bugs ) if you find any API which is lacking. The trouble with this reasoning is that the .sch file format is reasonably simple, well documented, expressive, extensible, and stable. The libgeda API is complex, poorly documented, and badly in need of revision. Only a few tools use the libgeda API, but there are many useful scripts out in the gEDA universe that deal with .sch and .sym files directly, so file format changes would be big trouble in any case. --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business go along to get along causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On 01/12/2011 01:29 PM, al davis wrote: There is a real problem with the interface to gEDA, and also with displaying the results. Does anyone want to help fix this problem Sure, just can't divert from the main project of creating the free time to do such. The first cuts of all my products in planning don't even need simulation so I can't justify time yet. I did get a little progress with verilog-ams for gnucap a while back though, so if anyone wants to send some tip money, I'll dig into it proportionately. JG ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On 1/14/2011 6:13 PM, John Griessen wrote: On 01/12/2011 01:29 PM, al davis wrote: There is a real problem with the interface to gEDA, and also with displaying the results. Does anyone want to help fix this problem Sure, just can't divert from the main project of creating the free time to do such. The first cuts of all my products in planning don't even need simulation so I can't justify time yet. I did get a little progress with verilog-ams for gnucap a while back though, so if anyone wants to send some tip money, I'll dig into it proportionately. Perhaps you can take inspiration from some other web sites and do your work in front of a web cam. Others can watch and when they are inspired, they can provide tips in real time. When you don't get enough tips you can stop working until they tip more... ;^) I won't say what web sites I've been watching lately... 8-] Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 14, 2011, at 6:32 AM, Peter Clifton wrote: Ideally (to be forward compatible with format changes), that plugin would use libgeda. If someone starts on this, please let us know via the lists + bug tracker ( https://launchpad.net/geda/+bugs ) if you find any API which is lacking. On Friday 14 January 2011, John Doty wrote: The trouble with this reasoning is that the .sch file format is reasonably simple, well documented, expressive, extensible, and stable. The libgeda API is complex, poorly documented, and badly in need of revision. Only a few tools use the libgeda API, but there are many useful scripts out in the gEDA universe that deal with .sch and .sym files directly, so file format changes would be big trouble in any case. You have a point ... Without getting into the quality of the format or libgeda, lets assume that both are likely to change in the future in some way. The Gnucap plugin system allows many plugins for many different formats. It is reasonable to expect that when the format changes there could be plugins for both the new and old versions, providing a migration path between them. If libgeda changes, which it will need to if it will support the new format or new features that may be needed, any code using it also needs to change, causing maintenance issues. If something is written, it is not known whether whoever writes it will want to make the changes as libgeda changes. Besides, it may be necessary to keep the old one around for backward compatibility. It is better to eliminate such a burden. Reading a file is easy. The hard part about the geda format, where use of libgeda may be advantageous, is establishing connectivity. I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 12, 2011, at 11:29 AM, al davis wrote: Both of these are areas where we could take the lead, but I need help to do that. I can't do it alone, and can't do it if people are fighting it. Does anyone want to help? On Wednesday 12 January 2011, Edward Hennessy wrote: I would like to help with this project. That's great. There is a long list of things that need to be done. Where do you want to start? My preference is to start with netlist translation, using gnucap's translator system that goes both ways. In this case, that's a language plugin, reading and writing the gschem format, then another language plugin for the PCB format. al. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Dietmar Schmunkamp wrote: Start a design with gschem -- simulate it -- get it thru pcb -- extract physical paramaters from the layout -- OPTIMIZE* -- feedback to gschem -- restart the loop. On Friday 07 January 2011, Kai-Martin Knaak wrote: Unfortunately, at the current state of geda and friends the simulate step is a weak spot. Not so much because of weaknesses in the simulation algorithm. With gnucap and ngspice there are two very capable engines. It is the absence of readily available models and almost no GUI support that blocks the road. Actually, not at all because of weaknesses in the simulation algorithm. NGspice has essentially the same algorithms as LTspice. When I benchmarked them (a few years ago) they were indistinguishable, which makes sense because they are both derivatives of Spice-3 from Berkeley, which also is mostly indistinguishable in a performance sense. Gnucap has more advanced algorithms. My benchmarks show much faster performance on large circuits and more robust time step control. Ironically, switch mode power supply is a type of circuit that works fine on gnucap, but I got identical believable bad results on both NG and LT spice, due to step control problems. There is a real problem with the interface to gEDA, and also with displaying the results. Does anyone want to help fix this problem There is somewhat of a problem with models, because most models are written for a specific simulator and moving to another makes a lot of them not work. There are several strategies for improving this situation, ranging from adding features to the simulator to porting models. Both of these are areas where we could take the lead, but I need help to do that. I can't do it alone, and can't do it if people are fighting it. Does anyone want to help? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 12, 2011, at 11:29 AM, al davis [1]ad...@freeelectron.net wrote: Both of these are areas where we could take the lead, but I need help to do that. I can't do it alone, and can't do it if people are fighting it. Does anyone want to help? I would like to help with this project. Cheers, Ed Sent from my iPhone References 1. mailto:ad...@freeelectron.net ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Colin D Bennett wrote: The orthogonality of these three pieces (schematic, footprint mapping, and PCB layout) is pleasing to me, but I have to admit that you would rarely find a need to create different PCBs from the exact same schematic. ack. Up to now, I _never_ had this situation in real projects. Some aspect of the schematic beyond footprints and packages always needs to be changed. On the other hand: Almost all projects need debugging and/or service. For this task, footprints printed on the schematic help to locate the part in the layout. Still, by separating the footprint mapping entirely from schematic capture, you can stay focused on one task at a time. If this is your preferred way to work, you can already do it, even with heavy symbols: Just ignore the footprint attribute while placing symbols. Use gattrib, a text editor or a script to replace dummy values of the footprints in a separate step. The mere fact that the footprint information is contained in the schematic does not imply, you have to set it during schematic capture. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Fri, 07 Jan 2011 20:21:29 +0100 Kai-Martin Knaak kn...@iqo.uni-hannover.de wrote: Colin D Bennett wrote: The orthogonality of these three pieces (schematic, footprint mapping, and PCB layout) is pleasing to me, but I have to admit that you would rarely find a need to create different PCBs from the exact same schematic. ack. Up to now, I _never_ had this situation in real projects. Some aspect of the schematic beyond footprints and packages always needs to be changed. On the other hand: Almost all projects need debugging and/or service. For this task, footprints printed on the schematic help to locate the part in the layout. Still, by separating the footprint mapping entirely from schematic capture, you can stay focused on one task at a time. If this is your preferred way to work, you can already do it, even with heavy symbols: Just ignore the footprint attribute while placing symbols. Use gattrib, a text editor or a script to replace dummy values of the footprints in a separate step. The mere fact that the footprint information is contained in the schematic does not imply, you have to set it during schematic capture. Thanks; these are both excellent points. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 07.01.2011 20:21, schrieb Kai-Martin Knaak: Colin D Bennett wrote: The orthogonality of these three pieces (schematic, footprint mapping, and PCB layout) is pleasing to me, but I have to admit that you would rarely find a need to create different PCBs from the exact same schematic. ack. Up to now, I _never_ had this situation in real projects. Some aspect of the schematic beyond footprints and packages always needs to be changed. On the other hand: Almost all projects need debugging and/or service. For this task, footprints printed on the schematic help to locate the part in the layout. Still, by separating the footprint mapping entirely from schematic capture, you can stay focused on one task at a time. If this is your preferred way to work, you can already do it, even with heavy symbols: Just ignore the footprint attribute while placing symbols. Use gattrib, a text editor or a script to replace dummy values of the footprints in a separate step. The mere fact that the footprint information is contained in the schematic does not imply, you have to set it during schematic capture. ---)kaimartin(--- Hi, maybe a little off topic and sorry to say, but I fear the discussion about soft/hard/light/heavy symbols is going to over-optimize a certain step in the design flow, the overall objective should be a working product. And to achieve that we need to put some feedback into the design loop. Start a design with gschem -- simulate it -- get it thru pcb -- extract physical paramaters from the layout -- OPTIMIZE* -- feedback to gschem -- restart the loop. I'm aware that this can't be done by one person (unless there you have infinte time), but each process step should propagate all knowledge/implications to the next step (wire impedance, shielding ...). I haven't pushed gaf/pcb to these limits yet, but ... my message is: Use any kind of inforamtion regardless where it has been gathered to be better next time. BTW: In my day job (chip design, and I am in a close loop with all pro's and con's :-) ) I had an example of just changing physical footprints: We had a ceramic module ($$$ and a huge manufacuring turn around time) with 4 silicon chips on it that was attached to a pcb. The footprint of each of hte 4 chips was fixed and the board layout was fixed, too. But to debug the 4 chips there were 2 flavours of the ceramic carrier: One ver y costly for the engineering hardware being capable of probing all chip interconnects and another costreuced (smaller) without exploiting all chip to chip interconnects. - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nok4ACgkQn22l+QvEah13uQCeM0GxhA91GPX+EdURdEvZ7obv VDMAni08Zv/8nnQ5+S53QCxngYKQI0cC =vcPr -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Stefan Salewski wrote: For footprint shape that is correct -- for slots and pin numbers not. Slot numbers and their influence on pin numbers can safely be ignored in the first stages of schematic capture. With single/dual/quad packages it is not that simple. No algorithm could reliably guess what the designer wants -- which symbols to merge, which pair to choose from a quad. The best gschem might do, is to offer a way to achieve these goals with a minimum hassle. Maybe some kind of multiple symbol mode. (I smell the scent of a feature request ;-) If I currently place an OpAmp symbol, its inverting, non-inverting and output pin have already pinnumbers, pinseq, and slotdef attribute. An enable or offset correction pin may exist or may not exist. So it is better to know ahead what you want. Regarding offset correction, you better do. If used, the offset needs extra components and nets. ---)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: Soft and Hard symbols
Kai-Martin Knaak k...@lilalaser.de writes: (I smell the scent of a feature request ;-) Like http://www.delorie.com/pcb/pin-mapping.html ? That lets the designer defer slot, package, and pin assignments until layout time. It assumes there's a unique identifier (not the refdes!) for each symbol, so PCB can swap/merge/assign gates across packages. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Dietmar Schmunkamp wrote: Start a design with gschem -- simulate it -- get it thru pcb -- extract physical paramaters from the layout -- OPTIMIZE* -- feedback to gschem -- restart the loop. Unfortunately, at the current state of geda and friends the simulate step is a weak spot. Not so much because of weaknesses in the simulation algorithm. With gnucap and ngspice there are two very capable engines. It is the absence of readily available models and almost no GUI support that blocks the road. ---)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: Soft and Hard symbols
On Mon, 03 Jan 2011 11:25:26 -0500 DJ Delorie d...@delorie.com wrote: Stefan Salewski m...@ssalewski.de writes: I guess all this was discussed on the list multiple times in the past, My thoughts: http://www.delorie.com/pcb/component-dbs.html You should be able to defer the selection of packages, pinouts, and part numbers until later in the design cycle. 100% right. There is (1) the schematic, with symbols, (2) the PCB layout with footprints and tracks, and then there is what I think should be part (3) a mapping from each schematic symbol to PCB footprint. Currently in the normal gschem/pcb workflow the footprints will be defined in the schematic. However, by extracting the symbol-footprint mapping to a separate (3) entity, you can create multiple different PCBs from the same schematic, or change footprints without revising the schematic itself. In theory you could create a through-hole component PCB and surface-mount component PCB from the same schematic. The orthogonality of these three pieces (schematic, footprint mapping, and PCB layout) is pleasing to me, but I have to admit that you would rarely find a need to create different PCBs from the exact same schematic. Still, by separating the footprint mapping entirely from schematic capture, you can stay focused on one task at a time. Regards, Colin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Soft and Hard symbols
I guess all this was discussed on the list multiple times in the past, so this is more a note to myself... I think it may be useful to have two types of symbols, soft and hard. Hard symbols have an footprint attribute and maybe additional hard properties. Soft symbols are simple an OpAmp or a resistor -- only type, no parameters defined. For schematic entry the use can select Add soft symbol or add hard symbol (if he exactly knows what he wants). If a schematic contains soft symbols, then there is an additional step necessary before PCB layout can start: Selecting footprints and slots -- this step may be supported by databases. (The user may have the optional choice to generate hard symbols from soft ones by specifying footprints and other hard facts in an early input stage.) Note, this is not what we currently have with our light/heavy symbols. The point is, that we should make a strict decision, not make a soft transition from light to heavy but adding some attributes. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
Stefan Salewski m...@ssalewski.de writes: I guess all this was discussed on the list multiple times in the past, My thoughts: http://www.delorie.com/pcb/component-dbs.html You should be able to defer the selection of packages, pinouts, and part numbers until later in the design cycle. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Jan 3, 2011, at 8:20 AM, Stefan Salewski wrote: I guess all this was discussed on the list multiple times in the past, so this is more a note to myself... I think it may be useful to have two types of symbols, soft and hard. Hard symbols have an footprint attribute and maybe additional hard properties. Soft symbols are simple an OpAmp or a resistor -- only type, no parameters defined. For schematic entry the use can select Add soft symbol or add hard symbol (if he exactly knows what he wants). If a schematic contains soft symbols, then there is an additional step necessary before PCB layout can start: Selecting footprints and slots -- this step may be supported by databases. (The user may have the optional choice to generate hard symbols from soft ones by specifying footprints and other hard facts in an early input stage.) Besides allowing attributes to contain a value representing unknown or be empty, I don't see why the application needs to know the difference between a hard and soft symbol. If the schematic editor allows empty attributes and allows the user to edit these attributes, wouldn't it be capable of the functionality requested above? Note, this is not what we currently have with our light/heavy symbols. The point is, that we should make a strict decision, not make a soft transition from light to heavy but adding some attributes. Cheers, Ed ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Mon, 2011-01-03 at 16:04 -0800, Edward Hennessy wrote: On Jan 3, 2011, at 8:20 AM, Stefan Salewski wrote: I guess all this was discussed on the list multiple times in the past, so this is more a note to myself... I think it may be useful to have two types of symbols, soft and hard. Hard symbols have an footprint attribute and maybe additional hard properties. Soft symbols are simple an OpAmp or a resistor -- only type, no parameters defined. For schematic entry the use can select Add soft symbol or add hard symbol (if he exactly knows what he wants). If a schematic contains soft symbols, then there is an additional step necessary before PCB layout can start: Selecting footprints and slots -- this step may be supported by databases. (The user may have the optional choice to generate hard symbols from soft ones by specifying footprints and other hard facts in an early input stage.) Besides allowing attributes to contain a value representing unknown or be empty, I don't see why the application needs to know the difference between a hard and soft symbol. If the schematic editor allows empty attributes and allows the user to edit these attributes, wouldn't it be capable of the functionality requested above? At least the slotdef attribute is an example where we currently have to make a decision in an very early design stage. If I know that I may need some OpAmps or logic gates for my design, I may want to do not care about single, dual or quad packages when drawing the schematic. But currently we have to pick one of these types -- later we may have to replace it. For many tasks heavy/hard symbols may be fine -- when we know in advance what we need. But I really would like to have the ability to do a top down design: OpAmp - VoltageFeedback - FetInput - Dual - SOT8 Similar like selection at Digikey -- and now I remember postings of DJ, I really should read his http://www.delorie.com/pcb/component-dbs.html and try to understand it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
From: m...@ssalewski.de To: geda-user@moria.seul.org Date: Tue, 4 Jan 2011 03:17:21 +0100 Subject: Re: gEDA-user: Soft and Hard symbols At least the slotdef attribute is an example where we currently have to make a decision in an very early design stage. If I know that I may need some OpAmps or logic gates for my design, I may want to do not care about single, dual or quad packages when drawing the schematic. But currently we have to pick one of these types -- later we may have to replace it. Stating the obviuous... How about this kind of situation. Let's say you are designing low-pass filter for mono signal and you have readily world's best quad opamp on your part box and symbol is there and SPICE model is there. Due to case you need to use slot three to fit all the resistors and caps because there is space on the enclosure. With this situation, there are two schematics. One for spice and onether for pcb. Ofcourse this is hobby example and gEDA should be considered professional tool :) But are those commercial situations so far away from that? I don't think that it is too hard to add the modelfile attribute for symbol, since it can be anywhere in the system. http://www.delorie.com/pcb/component-dbs.html I really liked DJ's ideas. I wish I was able to help, but gEDA is still too far away from my skils. best regards, Hannu Vuolasaho ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
