gEDA-user: Hurray for GUI!
Yesterday, I made a bunch of symbols with the web version of djboxsym. Very handy. GUI as it should be: an effective assist to a necessarily manual graphical process. Thanks DJ! But may I make a feature request? The majority of my from scratch box symbols do not represent things with pin numbers: they represent hierarchical subcircuits. djboxsym uses the numbers both for visible pinnumber= and invisible pinseq= attributes (good). But I'd like an option to have only the pinseq= attributes. -- 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: why separate xgsch2pcb?
Mark Stanley wrote: And I understand how the schematic might be automated as it is just a visual representation of a net list, but I just can't imagine how on earth you could layout a board without ever looking at it. Or is that even what you are talking about? Think of it as two processes: design and layout. In the design process, the human inputs are schematics, text, tables, source code, etc. The data products are netlists, BOMs, simulations, graphics, documentation, programs, etc. Ideally in design automation, the flow from the inputs to the data products is fully automatable, so a single command can generate all of the data products from the inputs. If you change a drawing, you shouldn't have to push a bunch of buttons to get it into the documentation, for example. Layout takes some of the data products from design, and with additional human inputs, produces more data products: gerbers, pick and place, mask sets, layout-derived netlists, more documentation, etc. Again, it is desirable to be able to get the data products hands off once the human inputs are in. It is good to have an interface here. The automation breaks at the start of layout, for the reasons you note. My customers all have their preferred layout people and processes: gEDA supports them all well (so easy to write a gnetlist back end). And nobody will ever do an ASIC layout with pcb. -- 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: why separate xgsch2pcb?
John Griessen wrote: DJ Delorie wrote: Probably the simplest approach (which I'm leaning towards) is to treat the netlist file as the target, keep that up-to-date, then let With the new PCB import code, there's no more netlist file :-O No more netlist file! :-O Oh Nooo... :-O Just kidding, but... This needs to be clarified before John Doty sees it or ? Why would that bother me? There's a file that contains netlist information and more. That happens in other flows, too. Very often some BOM data makes it into the netlist. -- 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: Ubuntu package for 1.6 and footprints
R. Bosch wrote: B.t.w.: Just noticed that it's almost a year since 20081128 was released. Any idea why it never came in Ubuntu? Which is still at 20080202... :-/ Hmm, Ubuntu Jaunty is at: gEDA/gschem version 1.4.3.20081231 Be nice if 1.6 was there, but it's not as bad as you say. -- 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: multi-part symbol support
Kai-Martin Knaak wrote: It took me quite a while to flex my hacking muscles. Anyway, finally my little hacking project reached a stage that actually represents an improvement: When dealing with footprints my local version of gnetlist does not care for the order of symbols anymore. If there is a set of symbols with the same refdes, only one needs to bear a footprint attribute. It doesn't matter which one. The generic case is symbols with power pins split to a separate power symbol. This is indeed an improvement. Your logic is good. But it's only a partial fix. There are many attributes that need similar treatment. Anything that goes into a BOM, for example. That's an open ended list, since I think many of us use custom attributes for our flows. A one-shot solution for each attribute won't work. Nor, I think, is it right to do this for all attributes, as source is potentially properly multiple, and we shouldn't preclude other such attributes. Now, source is handled by the front end, so at the moment it's outside this discussion, but I consider that to be a bug, too: it precludes making hierarchical back ends. I think it would be better to have a function gnetlist:get-all-attributes that returns a list of lists of (name, value) pairs, e. g. ( ( (refdes R1) (footprint 0603) (value 680) ) ( (refdes C1) (footprint 0805) (value 470 pF) ) ) Then, change gnetlist:get-package-attribute to a scheme procedure in gnetlist.scm, with your logic implemented there for all attributes. That shouldn't break any existing back ends, since gnetlist:get-package-attribute only returns a single attribute value anyway, but it puts the control in the back end, where it's flexible and configurable. Where it belongs. If you want to collaborate on this, I'll volunteer to do the easy part ;-). That, of course, is the handful of lines of Scheme that need to be added to gnetlist.scm (filtering data structures is easy). You've already done the really hard part, which is penetrating the logical structure of the front end: all you'd need to do is compose gnetlist:get-all-attributes. In addition, gnetlist detects if there are different footprints attached to a single refdes and warns accordingly. Unlike what I had in mind last week, this this not achieved by merging symbols in the internal representation. Instead, gnetlist copies the footprint attribute to all symbols with the same refdes. So no data is lost during this additional preprocessing stage. I'd like to see this bug fixed in the main distribution of geda, too. How would I go ahead? Should I send the patch files to this list for a review? Or should I attach them to a bug report? ---(kaimartin)--- -- 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: merge multi symbol components
DJ Delorie wrote: Well, you have to *use* its scriptability, and not fight against it. I don't consider it scriptable unless you can invoke the script from within the tool and have it operate on the live data. Different kind of scriptabilty than I'm talking about. The question is: can a scripting program like make practically operate the tool, or is a human operator required? Power tool versus hand cranked tool. Layout is necessarily a sore spot here, as it requires human input. So, barring improvements in AI technology, it's necessarily a barrier to scriptability. Can't complain there. But design and layout are not all there is. Documentation, simulation, device drivers, etc., etc. It's a real time saver to have the builds of all of these things automated. Check the files out from the revision control system, then make to get all of the project data products: printable graphics, text, programs, etc. gEDA's strength is that it works extremely well in this kind of approach: it doesn't unnecessarily demand human input, and it plays well with other power tools. You should be able to, for example, right-click on a menu button and edit the script it will run, then left-click on it to run it. No buttons, no clicks. Just text. That's scripting. Even pcb with all its actions is only half way there. A specialized internal language is a poor way to get scriptability. I don't consider pcb's actions scripts, more of a batch file. However, you have to *start* with a solid collection of verbs and nouns before you can build a scripting system around it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- 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: g_list_sort() or local mergesort?
Kai-Martin Knaak wrote: For my gnetlist hacking I need to sort the netlist according to refdes. There are two options: a) use the function g_list_sort() provided by glib This would involve routines to convert NETLIST to GList and back. b) add a sorting algorithm to libgeda. A sensible choice would be mergesort. Which option do you prefer? How about: c) Crib the refdes sorting code from spice-sdb.scm? ---(kaimartin)--- -- 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: gnetlist missing features
Stefan Salewski wrote: There was some discussion about netlist generation on this list recently, so maybe it is a good time to speak about missing features: I have some OpAmps with power down pins (active low) in my schematics, I have connected an io symbol to it with an attribute like net=PreAmpPD:1. If I connect this io symbol (a copy) to an other device, i.e. to a pin of an FPGA all is fine. Now I decide this OpAmp should be always on, so I make a copy of this io symbols and connect it to a (lonesome) power symbol with a net attribute like net=3.3V:1. So the power symbol and one instance of the io symbol are connected to each other, with no direct connection to other real hardware. I think this will not work correctly, the power down pin of the OpAmp will not be connected to the 3.3V rail as desired. You've told gnetlist to short PreAmpPD to 3.3V. What happens then is undefined. My experience is that gnetlist's behavior is difficult to predict in such cases: sometimes it chooses one net name over another, and sometimes it leaves the nets unconnected. Another example is a subcircuit containing a short circuit between two external connections. The nets in the higher level schematic don't get connected. But this is a perfectly reasonable object when you consider that a subcircuit may have different implementations in different versions of a circuit whose higher level description doesn't change. The question then is: what is a simple set of logical rules that should govern shorted nets? These should somehow capture the intuitive understanding the designer has when drawing such a thing. What is this? Is your understanding similar to mine? Are additional attributes needed to describe this? Will such attributes be comprehensible to the designer? The most pressing need here is for gnetlist to detect shorts and warn the user of their resolution. It would be very nice if this would work -- I think we had a discussion about this problem long time ago on the list. The other topic: There are ICs with multiple power- or output pins for low impedances. It would be nice to allow pinnumber=4,5,6,7 in symbols to indicate that this visible power pin in the schematic should indicate a connection to pins 4,5,6,7 of the related footprint. (My current solution is to make a local copy of the footprint, have pinnumber=4 in the symbol and rename pads 4,5,6,7 to 4,4,4,4 in the footprint and so on) Best wishes, Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- 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: spNet v0.9.2 released
Anthony Shanks wrote: http://spnet.code-fusion.net More of a beta/trial release, but I've done considerable testing with both my symbol libraries and the default gEDA libraries and everything for the most part seems smooth. For those of you who aren't familar with spNet, it's a spice netlister for gEDA that can netlist hierarchical schematics using the spice .subckt directive (which are easier to read and simulate faster). Note that there was never any serious difficulty doing this with gnetlist -g spice-sdb and a makefile. It also has many more features detailed in the documentation (up to date now on the homepage). If anybody has any questions or any issues with spNet let me know. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- 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: spNet v0.9.2 released
A.Burinskiy wrote: John, Could you please explain in detail, what does your comment mean? Start with http://www.brorson.com/gEDA/SPICE/intro.html It is useful to disable gnetlist hierarchy traversal as described in http://archives.seul.org/geda/user/Nov-2008/msg00487.html Then, set up your makefile to turn each subcircuit schematic into a circuit file. A handy rule might be: %.cir : %.sch gnetlist -q -g spice-sdb -I --nomunge -o $@ $^ Then, maybe assemble the combined file as follows: CIRCUITS=top.cir sub1.cir sub2.cir combined.cir : $(CIRCUITS) cat $(CIRCUITS) combined.cir So, when you type make combined.cir you'll update subcircuit files as necessary and combine them into the final product. This is especially useful when additional processing (e.g. spicepp.pl) is needed and when some subcircuits are generated by some other tool than gnetlist. Simple and extremely flexible. This is a stripped-down version of the more elaborate flow I use for IC design, and may require tweaking for your flow. But the important thing is that it's easy to customize: you're not trapped by the decisions somebody else made to support *their* flow. That's the gEDA way. That's why gEDA is so much better than other packages. /* Note that there was never any serious difficulty doing this with gnetlist -g spice-sdb and a makefile. */ Thanks, Alex. On 06/30/2009 11:48 AM, John P. Doty wrote: Anthony Shanks wrote: http://spnet.code-fusion.net More of a beta/trial release, but I've done considerable testing with both my symbol libraries and the default gEDA libraries and everything for the most part seems smooth. For those of you who aren't familar with spNet, it's a spice netlister for gEDA that can netlist hierarchical schematics using the spice .subckt directive (which are easier to read and simulate faster). Note that there was never any serious difficulty doing this with gnetlist -g spice-sdb and a makefile. It also has many more features detailed in the documentation (up to date now on the homepage). If anybody has any questions or any issues with spNet let me know. ___ 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 -- 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: spNet v0.9.2 released
Anthony Shanks wrote: What do you mean? Unless you mean downloaded subckts from vendors, spice-sdb is irrelevant in hierarchically netlisting schematics you have drawn yourself. I do it all the time. I've designed several mixed-signal IC's that way. It's easy. Think flexible toolkit, rather than expecting an inflexible integrated tool. -- 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: spNet v0.9.2 released
Anthony Shanks wrote: On Tue, Jun 30, 2009 at 11:59 AM, Bill Gatliffb...@billgatliff.com wrote: John P. Doty wrote: Anthony Shanks wrote: http://spnet.code-fusion.net More of a beta/trial release, but I've done considerable testing with both my symbol libraries and the default gEDA libraries and everything for the most part seems smooth. For those of you who aren't familar with spNet, it's a spice netlister for gEDA that can netlist hierarchical schematics using the spice .subckt directive (which are easier to read and simulate faster). Note that there was never any serious difficulty doing this with gnetlist -g spice-sdb and a makefile. You're a real buzzkill this week, you know that? :) First you don't like my idea, and now you don't like Anthony's either! :) :) Haha yeah, except I'm not sure what he says is accurate and I'm not sure what the resistance is against a hierarchical netlister (without workarounds like makefiles and such). A makefile isn't a workaround. It's a place to implement more flexibility. Every single industry level netlister I have ever seen does this and I have worked with plenty as a student and now an engineer in the industry. gEDA is superior to those tools: it does not take away your flexibility the way they do. It even plays nicely with tools that aren't designed to play nicely. As someone who manually looks at netlists on a daily basis, flat netlists are very hard to read and simulate slow in spice simulators. Agreed. But you if you thing gEDA is restricted to generating flat netlists, you don't understand it. You can't improve what you don't understand. I'm not even sure a makefile solution would really work anyway since flat netlisting each cell separately in a makefile (which I assume John was talking about) would not be able to automatically produce the subckt statements need inside the main spice file. Correct me if I am wrong. You're wrong. Haven't you studied spice-sdb? -- 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: spNet v0.9.2 released
Anthony Shanks wrote: I suppose makefiles are a matter of perspective. What you call flexibility I call a missing feature. In my opinion a robust spice netlister includes hierarchical netlisting and other features I included in spNet that I see out in industry. In your opinion netlisters should be bare bones and makefiles should be included in your flow. One of the best programmers of all time once said A program should do one thing well. So much waste could be avoided if people would just understand this simple principle. Ok thats fine. Whats the problem here? Are you always this hostile to people who try to contribute to the community? You have spread serious misinformation on this list. You claim hierarchical netlists cannot be generated using gnetlist. You have misrepresented how the existing gEDA SPICE netlisting works in other ways: you plainly don't understand the usage of the model= and model-name= attributes. That makes me hostile. As someone who is relatively new to the gEDA community I saw a huge gap in gnetlist and gspiceui for people interested in using gEDA for IC simulations so I thought I'd contribute. The gap is largely a result of not doing your homework. Study Stuart's stuff first. I started with making a new netlister and plan on making a new simulation gui comparable to what you see in industry. Again, why so hostile? This is the first time I've contributed to a open source project and never thought I'd be met with such hostility. Contributions are welcome. Misinformation isn't. On the positive side, your netlister does not get in the way: it is a separate program that one can ignore. That's a good thing. But please, don't claim advantages where you are ignorant of what you're comparing it to. From where I sit, gnetlist is an amazing tool. It's the main thing that makes gEDA a superior toolkit. -- 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: spNet v0.9.2 released
Anthony Shanks wrote: On Tue, Jun 30, 2009 at 2:39 PM, John P. Dotyj...@noqsi.com wrote: Anthony Shanks wrote: I suppose makefiles are a matter of perspective. What you call flexibility I call a missing feature. In my opinion a robust spice netlister includes hierarchical netlisting and other features I included in spNet that I see out in industry. In your opinion netlisters should be bare bones and makefiles should be included in your flow. One of the best programmers of all time once said A program should do one thing well. So much waste could be avoided if people would just understand this simple principle. Ok? Not sure how this is relevant to spNet. When program 1 does function X, and program 2 does function Y, and they don't get in each others' way, it is folly to combine functions. Gnetlist is a *wonderful* netlister, radically flexible. Make is a wonderful orchestrator of processes and combiner of the results, radically flexible and efficient. It makes no sense to make something that cannot do a single thing that the combination of make and gnetlist can do, but combines them in a way that's much less flexible. Ok thats fine. Whats the problem here? Are you always this hostile to people who try to contribute to the community? You have spread serious misinformation on this list. You claim hierarchical netlists cannot be generated using gnetlist. I said gnetlist cannot generate hierarchical schematics. How is that not true? It's like saying your car can't go coast to coast. Of course it can't by itself, it needs a driver, gasoline stations, etc. Gnetlist does a wonderful job of creating netlists. Orchestrating SPICE hierarchy using gnetlist is a trivial scripting problem: it doesn't require a whole new tool. But you are welcome to provide such a tool: it won't be able to do most of the things you can do with the existing kit, but that's OK. You are not welcome to lie about the existing toolkit. You have misrepresented how the existing gEDA SPICE netlisting works in other ways: you plainly don't understand the usage of the model= and model-name= attributes. That makes me hostile. I'm not misrepresenting anything. Of course you are. I have working silicon that proves you can construct hierarchical SPICE netlists using the existing toolkit. All I stated in my original post is that I created a netlister that does hierarchical netlisting among other feature that gnetlist doesn't provide. The toolkit that includes gnetlist provides them. Which is true. Only in a narrow, legalistic sense. Misrepresentation. Why would that make you or anybody else hostile? Because you are making false claims. Others here are appreciating my work without being hostile nor have I been hostile to anybody on this list, nor have I insulted anyone. The people who seem to appreciate your work don't seem to understand gEDA. They expect something like the do everything poorly with one tool approach that is so distressingly common in software these days. A kit of tools, each of which does one thing well, is alien. But that's gEDA, that's its strength. As someone who is relatively new to the gEDA community I saw a huge gap in gnetlist and gspiceui for people interested in using gEDA for IC simulations so I thought I'd contribute. The gap is largely a result of not doing your homework. Study Stuart's stuff first. I admit I am not a veteran of the gEDA community but in my opinion I am filling a gap that the gEDA flow doesn't offer out of the box. You say that out of ignorance. You haven't done your homework. If you disagree that's fine but no reason to be hostile about it. If your tool is a good tool, you should not need to sell it by claiming the existing tools have limitations that only reflect your refusal to use the whole toolkit. Most of us don't need a hammer that also functions as a saw, and if you'd created one and claimed you can't build a house with a hammer it would be a misrepresentation. I started with making a new netlister and plan on making a new simulation gui comparable to what you see in industry. Again, why so hostile? This is the first time I've contributed to a open source project and never thought I'd be met with such hostility. Contributions are welcome. Misinformation isn't. Again, where have I given any misinformation? All you have done so far is prove there are workarounds the current flow. You don't understand a modular toolkit. Using each simple tool to do its job, and not burdening other tools with that job, is not a workaround: on the contrary it is the best way to get work done. On the positive side, your netlister does not get in the way: it is a separate program that one can ignore. That's a good thing. But please, don't claim advantages where you are ignorant of what you're
Re: gEDA-user: spNet v0.9.2 released
Bill Gatliff wrote: John P. Doty wrote: The people who seem to appreciate your work don't seem to understand gEDA. They expect something like the do everything poorly with one tool approach that is so distressingly common in software these days. A kit of tools, each of which does one thing well, is alien. But that's gEDA, that's its strength. For the record, I just said I liked his documentation and website--- and pled ignorance on everything else. :) Look, I'll first apologize for starting this whole thing by calling you names, John. I intended it in jest, but obviously my email didn't make that clear enough. Sorry. It was inappropriate behavior from me, to say the least. No need to apologize: I've a pretty thick skin. I don't even recall what you said. It had nothing to do with my distress. I agree that one of gEDA's strengths is that each component does one thing, and does it very well. That fact alone has made it much easier for me to get my head around the small parts of it that I need to get my relatively modest designs done. It looks like Anthony has re-invented a wheel, and that's difficult to accept. But his motivation to contribute is no less commendable as a result, and I really do appreciate his effort--- and I suspect that you do too, John. I know he would love to hear that. I appreciate his positive effort, indeed. But why must he falsely disparage what we already have? gEDA is a miracle: a lean, flexible toolkit in an age of complex, inflexible bloatware. In the bigger picture, I'll note that the tutorials and FAQs I've seen for gEDA all focus on a pretty specific workflow, which is to turn a schematic into a circuit board layout. There are obviously a zillion different ways that the tools would be useful, and I would really appreciate it if someone would write a few of them down! I'm working on a gnetlist back end tutorial. I think that the capabilities of gnetlist are underappreciated, and that specialized back ends could be very useful. I'm a Contributing Editor for Embedded Systems Design magazine. If anyone wants to help me co-author a few short articles on using gEDA for things like circuit board layout, schematic capture, simulations, and whatever else it's good for, I'd be more than happy to give you ample credit and to assist in whatever capacity I can to see to it that the documents get published. They should be good candidates for the Wiki, too! If we can get some word out, and commit to documenting some of the really cool ways people are solving problems with gEDA, then I think we'll all get along a _lot_ better. We'll focus our efforts on the parts of gEDA that are truly lacking (and even identify them!). And we'd call more attention to the project, too. bluto Now who's with me? /bluto b.g. -- 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: spNet v0.9.2 released
Bill Gatliff wrote: John P. Doty wrote: I'm working on a gnetlist back end tutorial. I think that the capabilities of gnetlist are underappreciated, and that specialized back ends could be very useful. Is your work-in-progress viewable on the wiki, or somewhere? I gotta learn to use the wiki. I showed people a fragment on the gEDA IRC a few weeks ago... b.g. -- 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: spNet v0.9.2 released
Anthony Shanks wrote: Yes I know exactly what you mean now and I have seen (and have used) that kind of hierarchy control present in very high end tools (like cadence) but it is usually at the schematic capture level like you stated rather at the netlister level. gschem would have to drastically change to support that level of hierarchical maniuplation. Not in the makefile approach. Define suitable attributes, process with a script, use the results to build the netlist from the pieces. Use the toolkit, don't fight it. Theoretically I can add some netlisting directive object at the top level schematic/testbench to handle this in spNet, but I'd have to look into how much work that would take. It would definately be a great feature though I agree with you. On Tue, Jun 30, 2009 at 4:06 PM, rnbs.pub...@gmail.com wrote: On Tue, Jun 30, 2009 at 11:10 PM, Anthony Shanksyamazak...@gmail.com wrote: - hierarchy configuration from top-level schematic, What do you mean by this? Say, you want to modify a subcircuit somewhere deep down the hierarchy or use an extracted netlist for some of sub-blocks. If there is no hierarchy configuration, you would have to modify all cells in the design starting from the swapped one up to the top level. With hierarchy configuration, you can specify that the sub-cell should be mapped to a particular cell view/architecture (e.g. extracted or schematic_for_openloop_gain_simulation). If this could be integrated with gschem, so that it knew which schematic it should descend to, that would be perfect. Unfortunately, AFAIK gschem has neither the notion of cell view nor the hierarchy configuration. One idea would be to add a text-like component on the top level schematic, say hierarchyConfiguration, where the user could write something like this: - # original_file_name file_name_to_be_used preamp.sch preamp_for_openloop_sim.sch analoglatch.sch analoglatch_extracted.sp # path_to_instance file_name /X5/X1/something something_else.sch - IMHO, having this information present and displayed on the top level schematic (testbench) is very convenient from the design management point of view. If it was to be added in a GUI or in makefile the information would have to be stored and handled separately. Regards, -r. ___ 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 -- 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: gnetlist - Found unknown component. Refdes..
Csanyi Pal wrote: Hi, I'm using gedasuite20080328 installed from tarball. When I'm running: gnetlist -v -g spice-sdb -o WPB_F18_PCB_v2_Prog.net WPB_F18_PCB_v2_Prog.sch gnetlist_error I get the messages: Much, perhaps all, of your trouble seems to be due to your use of the toxic IEC417/ground.sym, which is not a proper ground symbol. In general, you should not be using the IEC417 library symbols in schematics: they are only for block diagrams. Stuart fixed the ground symbol anyway (it's the most likely to cause trouble) at the January code sprint, but I suppose it hasn't made it to the version you're using. Use power/gnd-1.sym. --- 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: gnetlist - Found unknown component. Refdes..
Csanyi Pal wrote: John P. Doty j...@noqsi.com writes: Csanyi Pal wrote: I'm using gedasuite20080328 installed from tarball. When I'm running: gnetlist -v -g spice-sdb -o WPB_F18_PCB_v2_Prog.net WPB_F18_PCB_v2_Prog.sch gnetlist_error I get the messages: Much, perhaps all, of your trouble seems to be due to your use of the toxic IEC417/ground.sym, which is not a proper ground symbol. In general, you should not be using the IEC417 library symbols in schematics: they are only for block diagrams. Stuart fixed the ground symbol anyway (it's the most likely to cause trouble) at the January code sprint, but I suppose it hasn't made it to the version you're using. Use power/gnd-1.sym. Thanks, I used Power rails/gnd-1.sym and the error gone. I note that using a SPICE netlister on a schematic intended for PCB layout is not generally useful. A SPICE simulation needs sources that aren't in the schematic, and SPICE will think your connectors are FETs (J) and capacitors (C). In cases like this, I tend to snip out the piece I really need to understand and make a separate simulation schematic. -- 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: Found pins without the 'pintype' attribute:
Kai-Martin Knaak wrote: On Wed, 15 Apr 2009 12:37:09 -0600, John Doty wrote: You can ignore this. You can ignore most complaints from drc2: its model of reality is that you are designing pure logic circuits using a single logic family. To the developers: why bludgeon newbies with the need to use a tool that requires deep understanding of its limitations to be at all useful? Full ack. to this one. This lead me to not using DRC at all. I used it to help find Csanyi Pal's problem this morning. The combined messages from spice-sdb and drc2 led me quickly to the trouble But I needed my eight years of experience with gEDA to recognize the syndrome: none of the messages was a direct indication of what was wrong. I Assume, a better DRC is already on the agenda of features to be. Not that I know of. Can of worms... ---(kaimartin)--- -- 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: Using .global statements in GNUcap and mult transistors
al davis wrote: The Gnucap behavior is consistent with Hspice and Spectre. At least that is what I have been told. I don't have access to them to check it out. The behavior is an artifact of the implementation. In Gnucap, m works for all devices, including plugin models and subcircuits, even when the models as supplied do not explicitly implement it. I hope you haven't implemented the ngspice brain damage that causes it to apply the m= multiplier repeatedly for each successive analysis (your transistors grow as you proceed). I think I'd be using gnucap if it could do noise analysis. But I have a hacked up ngspice/spicepp combination that works with TSMC parameter sets, making it hard to change for just part of job. John Doty Noqsi Aerospace Limited ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Google SoC : Potential Candidate seeking Info
Kai-Martin Knaak wrote: On Tue, 17 Feb 2009 06:31:57 -0500, John Doty wrote: We concluded that Sage isn't quite ready to support this Would one of the following be fit for the job: gap ginac maxima mathomatic yacas Don't know. It takes work to find out. Can any of these associate a value with a *pattern* (not just a function or variable)? Mathematica's capabilities here are helpful. ---(kaimartin)--- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
