Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy
Steven Michalske smichal...@gmail.com writes:
pick a small set of some chips you care about. lets say a large
family of the AVR series.
To the symbol:
Add a virtual pin attribute
Add the pin map file attribute.
pinmap=ATmega16.fpm
device=ATmega16
footprint=TQFP44_10
{
And then offer a GUI to select from the list of footprints within
gschem.
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: spNet v0.9.2 released
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). 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
Re: gEDA-user: funny gnetlist warning
No. And I don't wish to, too. I actually meant the underscore in value=RIA_connect - maybe it is not the footprint name it is complaining about. ___ 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
Oops, had the website disabled. It's back up now. On Tue, Jun 30, 2009 at 1:04 AM, Anthony Shanksyamazak...@gmail.com 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). 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
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
John, Could you please explain in detail, what does your comment mean? /* 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
Re: gEDA-user: spNet v0.9.2 released
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! :) :) 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. I love the website and level of documentation--- keep up the good work. b.g. -- Bill Gatliff b...@billgatliff.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
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). 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. As someone who manually looks at netlists on a daily basis, flat netlists are very hard to read and simulate slow in spice simulators. 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. 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. I love the website and level of documentation--- keep up the good work. Thanks I appreciate it. I'm also in the middle of writing a replacement for gspiceui. b.g. -- Bill Gatliff b...@billgatliff.com ___ 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: spNet v0.9.2 released
Anthony Shanks wrote: 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). 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. As someone who manually looks at netlists on a daily basis, flat netlists are very hard to read and simulate slow in spice simulators. 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. All greek to me. I can totally appreciate the power of Spice et al., but the last time I used that kind of simulation was, oh, waayyy too many years ago and I authored the input files with vi--- they would easily have fit on a page. Yea, I use gaf today to capture schematics and lay out boards--- but that's just scratching the surface of what I can do. I'm still only skin-deep, too ignorant to have even a worthless opinion on the topic. :) b.g. -- Bill Gatliff b...@billgatliff.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
On Tue, 30 Jun 2009 12:08:55 -0700, Anthony Shanks wrote: Thanks I appreciate it. I'm also in the middle of writing a replacement for gspiceui. Are there any plans to reach a level of integration where I can select some subcircuit in gschem and press a simulate button? ---(kaimartin) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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
That framework of that level of integration I don't think exists of the gEDA flow as written since all of the tools are separate. The easiest way I think this is doable is for there to but a button in gschem that launches an outside script to netlist the current schematic and launch the simulation gui. Before we even think of that level of integration I think there needs to be a real simulation gui (which I am writing) to replace gspicui since it is missing so many feature and is not being updated. On Tue, Jun 30, 2009 at 12:23 PM, Kai-Martin Knaakk...@familieknaak.de wrote: On Tue, 30 Jun 2009 12:08:55 -0700, Anthony Shanks wrote: Thanks I appreciate it. I'm also in the middle of writing a replacement for gspiceui. Are there any plans to reach a level of integration where I can select some subcircuit in gschem and press a simulate button? ---(kaimartin) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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: funny gnetlist warning
On Tue, 30 Jun 2009 13:45:57 +0200, Duncan Drennan wrote: No. And I don't wish to, too. I actually meant the underscore in value=RIA_connect - maybe it is not the footprint name it is complaining about. I should have read the warning more closely: The offending detail was commas in the value attribute. Some questions spring to mind: Why are considered bad in this context? If commas in the netlist are not allowed and cannot be escaped, why not just replace them silently with an underscore? Is there any case when I need to be warned about the replacement? Suggestion: If the warning should remain, the wording should be more explicit. Maybe along the lines: Warning: commas in component value have been replaced by underscores. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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
On Tue, Jun 30, 2009 at 8:52 PM, John P. Dotyj...@noqsi.com wrote: 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. [...] You're wrong. Haven't you studied spice-sdb? John, I think everyone here has already got your point. Don't understand me wrong, I'm glad the current solution works for you but I hope you will agree that different people may have different needs. I, for one, am very happy that someone has stepped forward and wrote a netlister that is better suited to my needs. Whether Anthony has reused gnetlist or not - I couldn't care less. I haven't been using it (and thus the whole geda) anyway. Regards, -r. ___ 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
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. Ok thats fine. Whats the problem here? Are you always this hostile to people who try to contribute to the community? 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. 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. On Tue, Jun 30, 2009 at 12:52 PM, John P. Dotyj...@noqsi.com wrote: 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 ___ 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
On Tue, Jun 30, 2009 at 2:06 PM, rnbs.pub...@gmail.com wrote: On Tue, Jun 30, 2009 at 8:52 PM, John P. Dotyj...@noqsi.com wrote: 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. [...] You're wrong. Haven't you studied spice-sdb? John, I think everyone here has already got your point. Don't understand me wrong, I'm glad the current solution works for you but I hope you will agree that different people may have different needs. I, for one, am very happy that someone has stepped forward and wrote a netlister that is better suited to my needs. Whether Anthony has reused gnetlist or not - I couldn't care less. I haven't been using it (and thus the whole geda) anyway. Regards, -r. Thanks I appreciate it. Just for clarification I have not reused gnetlist at all the program has no dependencies. It's own netlister. ___ 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: spNet v0.9.2 released
Hi, The tool works very well (neat example, btw). Couple of observations and nice to have features: - project specific configuration (instead of putting everything in ~/.spnet*), - inferring the list of used libraries by reading ./.gafrc (instead of defining them in ~/.spnetlibs), - command line switches for disabling .END card, for putting top level schematic in a subcircuit, for putting each top-level subcircuit in separate netlists and include them in the top-level one etc. - better attribute names (like modelName instead of value), I guess you are trying to follow some gschem conventions but, to be honest, I don't really care much about compatibility with rest of gschem libraries (they tend to be pcb flow specific anyway), - hierarchical busses and parametrized subcircuits (I've seen this in todo list), - hierarchy configuration from top-level schematic, - FYI, I never use implicit netlisting features (global nets, three pin MOS devices, default channel length). Nevertheless, I've seen people here asking e.g. about .global cards so they might be valuable (unless they get in the way of other features). It would be cool to have some sort of generic netlisting templates for other simulators. I.e. instead of hardcoding spice code in the spnet, these chunks of netlist could be taken from a primitive device library (think: spice view, spectre view, veriloga view etc.). As for the GUI, I don't really miss it too much. Unless it is very elaborate it won't cover even half of features of modern simulators. IMHO, the simplest solution is to add a bunch of components like netlistHeader, netlistFooter, hierarchyConfiguration, runSimCmd or netlisterConfiguration, where the user can simply type missing spice cards, override spnet settings etc. Overall, great job! Thanks. -r. On Tue, Jun 30, 2009 at 8:30 PM, Anthony Shanksyamazak...@gmail.com wrote: That framework of that level of integration I don't think exists of the gEDA flow as written since all of the tools are separate. The easiest way I think this is doable is for there to but a button in gschem that launches an outside script to netlist the current schematic and launch the simulation gui. Before we even think of that level of integration I think there needs to be a real simulation gui (which I am writing) to replace gspicui since it is missing so many feature and is not being updated. On Tue, Jun 30, 2009 at 12:23 PM, Kai-Martin Knaakk...@familieknaak.de wrote: On Tue, 30 Jun 2009 12:08:55 -0700, Anthony Shanks wrote: Thanks I appreciate it. I'm also in the middle of writing a replacement for gspiceui. Are there any plans to reach a level of integration where I can select some subcircuit in gschem and press a simulate button? ---(kaimartin) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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 ___ 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
gEDA-user: deprecating gschem2pcb and PCBboard backend
Anyone have any objections to deprecating the gschem2pcb script and the PCBboard gnetlist backend that is used by that script? As far as I know nobody uses either of those anymore. Note that I'm talking about gschem2pcb and *not* gsch2pcb, the latter being what probably everyone uses. Why you ask? Because gschem2pcb doesn't really offer anything that gsch2pcb doesn't and the latter is what's used, developed, and supported. The existence of the former I think just serves to confuse new users and PCBboard additionally is there to annoy developers by it being in the test suite. The PCBboard backend is very similar to the gsch2pcb backend but again, the latter is seeing development and the former isn't. -Dan ___ 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
On Tue, Jun 30, 2009 at 1:39 PM, rnbs.pub...@gmail.com wrote: Hi, The tool works very well (neat example, btw). Couple of observations and nice to have features: - project specific configuration (instead of putting everything in ~/.spnet*), Good suggestion, I can probably do this by reading these files from the current working directory first and try ~/.spnet* if the files don't exist. - inferring the list of used libraries by reading ./.gafrc (instead of defining them in ~/.spnetlibs), Yes I have thought about doing that, maybe add that feature to the next version. - command line switches for disabling .END card, for putting top level schematic in a subcircuit, for putting each top-level subcircuit in separate netlists and include them in the top-level one etc. I see no problem with that. - better attribute names (like modelName instead of value), I guess you are trying to follow some gschem conventions but, to be honest, I don't really care much about compatibility with rest of gschem libraries (they tend to be pcb flow specific anyway), I agree but the attribute names will probably stay the same since I'm aiming this to be as compatible as possible with current gschem conventions. - hierarchical busses and parametrized subcircuits (I've seen this in todo list), Yep. - hierarchy configuration from top-level schematic, What do you mean by this? - FYI, I never use implicit netlisting features (global nets, three pin MOS devices, default channel length). Nevertheless, I've seen people here asking e.g. about .global cards so they might be valuable (unless they get in the way of other features). It would be cool to have some sort of generic netlisting templates for other simulators. I.e. instead of hardcoding spice code in the spnet, these chunks of netlist could be taken from a primitive device library (think: spice view, spectre view, veriloga view etc.). I suppose at a broader term this would be nice but I was really intending this netlister to be used for spice simulations (I.E. spice standard syntax). As for the GUI, I don't really miss it too much. Unless it is very elaborate it won't cover even half of features of modern simulators. IMHO, the simplest solution is to add a bunch of components like netlistHeader, netlistFooter, hierarchyConfiguration, runSimCmd or netlisterConfiguration, where the user can simply type missing spice cards, override spnet settings etc. Overall, great job! Thanks. -r. Thanks for your support! On Tue, Jun 30, 2009 at 8:30 PM, Anthony Shanksyamazak...@gmail.com wrote: That framework of that level of integration I don't think exists of the gEDA flow as written since all of the tools are separate. The easiest way I think this is doable is for there to but a button in gschem that launches an outside script to netlist the current schematic and launch the simulation gui. Before we even think of that level of integration I think there needs to be a real simulation gui (which I am writing) to replace gspicui since it is missing so many feature and is not being updated. On Tue, Jun 30, 2009 at 12:23 PM, Kai-Martin Knaakk...@familieknaak.de wrote: On Tue, 30 Jun 2009 12:08:55 -0700, Anthony Shanks wrote: Thanks I appreciate it. I'm also in the middle of writing a replacement for gspiceui. Are there any plans to reach a level of integration where I can select some subcircuit in gschem and press a simulate button? ---(kaimartin) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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 ___ 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: spNet v0.9.2 released
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. 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? 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. 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. Which is true. Why would that make you or anybody else hostile? Others here are appreciating my work without being hostile nor have I been hostile to anybody on this list, nor have I insulted anyone. 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. If you disagree that's fine but no reason to be hostile about it. 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. 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. I'm glad you're so warm and welcoming to outsiders. You have problems man. -- 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 ___ 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
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
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
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. 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. 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 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. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Cheap Graphic LCD project
A few weeks ago we discussed an inexpensive graphic LCD that Electronic Goldmine has been selling for a few years. It uses an elastomer contact and the only footprint available was in Eagle. I dumped some gerbers for the device out of Eagle and used the coordinates to build a PCB footprint. I've got a little project underway to test this out: http://members.cox.net/ebrombaugh1/synth/dsPIC_lcd/index.html I've got a bit more checking to do before sending the design off for fab, but hope to have something going soon. Once I've tested it I'll make the design files available for anyone else who is interested. (Yes, I know there are other sources of inexpensive monochrome LCDs. But I've got a bunch of these and want to try them out). Eric ___ 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: 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
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? b.g. -- Bill Gatliff b...@billgatliff.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
I'm not going to go back and forth anymore about the topic because I'm not sure anybody is benefiting from it but I'll say this: I didn't mean to offend or insult anybodys work. If I came across as such I apologize. I *personally* felt gnetlist itself (not the whole gEDA flow or toolkit, the gnetlist program itself) could use a few more important features so I decied to write my own netlister. Simple as that. I wasn't looking to invalidate anybodys work or re-invent the wheel. Just offering *in my opinion* an easy alternative to anyone who wants to make hierarchical schematics and doesn't want to make makefiles for their specific flow. Just run the netlister and you're done. If you don't like it, cool, just offering my program for those who are interested and it looks like at least a few so far are. Simple as that. On Tue, Jun 30, 2009 at 6:07 PM, John P. Dotyj...@noqsi.com wrote: 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 ___ 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
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. 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
gEDA-user: 3D Directed Graph / CAD Software for Direct Wiring Layouts?
I have had great success with using the Dia diagramming program for doing perfboard prototype layouts. Now I am contemplating direct wiring or possibly a combination of stacking surfboards and direct wiring. For this, I think a 3D visualization tool would be very important. Does anyone know of 3D directed graph software? I'm looking for something like one of those molecule viewers where you can click and drag things to rotate them but also like a CAD tool where I can define a cylinder or block with dimensions and so on. Has anyone heard of such a thing? Preferrably free and Free? Mike ___ 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'm not going to go back and forth anymore about the topic because I'm not sure anybody is benefiting from it but I'll say this: I didn't mean to offend or insult anybodys work. If I came across as such I apologize. I *personally* felt gnetlist itself (not the whole gEDA flow or toolkit, the gnetlist program itself) could use a few more important features so I decied to write my own netlister. Simple as that. I wasn't looking to invalidate anybodys work or re-invent the wheel. Just offering *in my opinion* an easy alternative to anyone who wants to make hierarchical schematics and doesn't want to make makefiles for their specific flow. Just run the netlister and you're done. If you don't like it, cool, just offering my program for those who are interested and it looks like at least a few so far are. Simple as that. how does spNet compare to gnetman which is also an alternative hierarchical spice netlister for gschem? On the topic of gspiceui replacements I think the trick is to write a GUI tool that is fairly generic and can read in at runtime an ascii description of the available simulator analysis types and their options. The GUI tool would then on the fly build the required dialog boxes. FWIW this is sort of how the export dialogs in PCB work. The export HID's define an attribute list and the actual gui code is never touched. The GUI's look at that attribute list and build dialogs with tooltips and everything at runtime. Then fully document that interface and leave it to the simulator distributions to keep that file up to date. Otherwise I think you'll never ever have something that is in sync with even one simulator much less more than 1 (different versions of spice count as more than 1). -Dan ___ 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: Now who's with me?
John P. Doty wrote: Bill Gatliff wrote: 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. I am. I've spent some time on testing and documenting the gnetlist-verilog scheme language backend to help use the Gnucap simulator with gschem schematics. The gnetlist-verilog back end outputs a subset of verilog-ams, which is fully hierarchical. I'd like to get that to some more workable state -- it already did some hierarchic netlisting -- but I have not done the unit tests for it or written it up. Bragging on something like that kind of gnetlist to gnucap integration could get more Linux_Fund contributions to help with PCB using the same things -- putting out a new version of the gnetlist-pcb netlist with circuit values for the trace capacitances and distances. John Griessen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Now who's with me?
Bragging on something like that kind of gnetlist to gnucap integration could get more Linux_Fund contributions to help with PCB using the same things -- putting out a new version of the gnetlist-pcb netlist with circuit values for the trace capacitances and distances. The LF netlister is all new anyway, I could add more attributes if needed. The thing is, PCB doesn't do anything with them at the moment. How would gschem know about trace capacitances anyway? The netlister is only sch-pcb at the moment. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Now who's with me?
DJ Delorie wrote: -- putting out a new version of the gnetlist-pcb netlist with circuit values for the trace capacitances and distances. The LF netlister is all new anyway, I could add more attributes if needed. [jg]I read here: http://www.linuxfund.org/projects/pcb/proposal/ that the LF netlister means forward annotation. The thing is, PCB doesn't do anything with them at the moment. How would gschem know about trace capacitances anyway? The netlister is only sch-pcb at the moment. [jg]I wasn't thinking of the gschem representation of the design getting back annotated, just a separate simulation version of the design schematic. A subset that is the zone of interest for simulation purposes. Hmmm... back annotation -- I guess a good way would be similar to the way PCB handles an imported netlist -- it shows rat-nest lines and notes how many missing nets there are. That kind of functionality in gschem would be handy for adding trace capacitance lumped parameter components to a simulation schematic. You would not want all of the netlist usually, just the part you are simulating, so having a way to export only some from pcb would be a good way. Drawing a polygon on a layer so it contains the traces you want exported for back annotation is what I think of first for selecting a zone of interest for simulating. Then the back annotation file could be a difference file -- a to do list of changes to make just like the .pfa forward annotation file in the LF proposal. I guess my idea doesn't fit in the LF proposal after all -- it would mostly be an addition to gschem rather. To add gschem functions that let you load a netlist, then add components to match it as in pcb layout. Instead of that, you could just handle little cases like trace capacitance as a special feature of wires, but that would be specific and a fair amount of work.To import new netlist elements would be general and more power/flexibility. So the short answer is: gschem would know about trace capacitances by getting a match the netlist mode as well as the extract the netlist from the current state of the schematic mode it has now. John Griessen -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Now who's with me?
The LF netlister is all new anyway, I could add more attributes if needed. [jg]I read here: http://www.linuxfund.org/projects/pcb/proposal/ that the LF netlister means forward annotation. Right, gschem-pcb is forward. pcb-gschem is back annotation. I guess my idea doesn't fit in the LF proposal after all -- it would mostly be an addition to gschem rather. To add gschem functions that let you load a netlist, then add components to match it as in pcb layout. That would be back annotation. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy
On Tue, Jun 30, 2009 at 2:54 AM, Stephan
Boettcherboettc...@physik.uni-kiel.de wrote:
Steven Michalske smichal...@gmail.com writes:
pick a small set of some chips you care about. lets say a large
family of the AVR series.
To the symbol:
Add a virtual pin attribute
Add the pin map file attribute.
pinmap=ATmega16.fpm
device=ATmega16
footprint=TQFP44_10
{
And then offer a GUI to select from the list of footprints within
gschem.
It would be so cool if you could call pcb to render the footprint in a
little window as a part of that GUI. This might make dependencies a
mess though.
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.com/
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
