Re: gEDA-user: gnetlist backend
On Jun 9, 2011, at 9:50 PM, Frank Thomson wrote: The netlist requires these PADS in the top level schematic be listed at the top of the netlist file, normally I can access pins of an instance by passing a uref to one of the gnetlist primitives (forget which one) and getting back a list of pins but I cannot do that for the very top level schematic, it seems to not have a uref or any way to say give me a list of pins that are in the top level. Pins are for symbols. You could make a top-level symbol, set source= to the top level schematic, and then place that symbol in its own over-the-top schematic. That's good for simulation, too. Or, you can make component symbols representing pads. That's what I do: see http://www.gedasymbols.org/user/john_doty/symbols/openIP/02-pads.html 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 backend
On Thu, Jun 9, 2011 at 10:50 PM, Frank Thomson fr...@frankthomson.net wrote: I'm not quite sure what you're asking, but perhaps (gnetlist:graphical-objs-in-net-with-attrib-get-attrib) is the function you seek. hierarchical) we have a top level schematic with instances (gates and modules we've designed ) with IPADS/OPADS/IOPADS to basically act as package pins. The netlist requires these PADS in the top level schematic be listed at the top of the netlist file, normally I can access pins of an instance by passing a uref to one of the gnetlist primitives (forget which one) and getting back a list of pins but I cannot do that for the very top level schematic, it seems to not have a uref or any way to say give me a list of pins that are in the top level. Or if it could do give me a list of objects that are in the top level, I could find the iopads but again I can't find a way to do that either. So I am asking if it is possible to tell gnetlist to go to the top level schematic in the hierarchy and return to me the IPADS/OPADS/IOPADS or something similar. Since pins are only valid in symbols, give the xPADS component instances an attribute to key on. Check out the spice-sdb backend's `spice-sdb:get-spice-IO-pins'. The convention in that case is to only collect i/o pins if there is a component with a `device=spice-subcircuit-LL' present in the schematic. Components with a `device=spice-IO' attribute are collected for pin names. On my schematics for IC work (lots of hierarchy), the pin component attribute convention is: device=spice-IO port-type=foo refdes=PIN_NAME value=1 A patch to spice-sdb sorts these by the `value=' attribute instead of the refdes. That and other mostly gnetlist-related patches are in my local fork at: http://repo.or.cz/w/geda-gaf/whiteaudio.git (whiteaudio branch) Dan -- SDG www.whiteaudio.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist backend
Original Message Subject: Re: gEDA-user: gnetlist backend From: Dan White d...@whiteaudio.com Date: Thu, June 09, 2011 9:29 pm To: gEDA user mailing list geda-user@moria.seul.org Since pins are only valid in symbols, give the xPADS component instances an attribute to key on. Check out the spice-sdb backend's `spice-sdb:get-spice-IO-pins'. The convention in that case is to only collect i/o pins if there is a component with a `device=spice-subcircuit-LL' present in the schematic. Components with a `device=spice-IO' attribute are collected for pin names. On my schematics for IC work (lots of hierarchy), the pin component attribute convention is: device=spice-IO port-type=foo refdes=PIN_NAME value=1 A patch to spice-sdb sorts these by the `value=' attribute instead of the refdes. That and other mostly gnetlist-related patches are in my local fork at: http://repo.or.cz/w/geda-gaf/whiteaudio.git (whiteaudio branch) Dan -- SDG www.whiteaudio.com Thanks for the thoughts, I was hoping to avoid extra attributes but it may be the solution. I'll take a look at the spice-sdb backend and also at your gEDA fork. Since you are also doing IC work, if you happen to know of an open source detail or maze router please let me know. -Frank ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist backend
I'm working on a backend for gnetlist and have a minor problem, the top level schematic has IPAD/OPAD/IOPADs that i need to list in the netlist but I can't find a way to directly address the top level schematic, it doesn't seem to have a uref I can use to reference it. It does have a unique attribute and I can access it fine using 'gnetlist:get-toplevel-attribute', but I just basically need to get the pads from the top level schematic so I can list them in the netlist. Any hints? Did I miss something in the wiki? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist backend
On Jun 9, 2011, at 4:18 PM, fr...@frankthomson.net fr...@frankthomson.net wrote: I'm working on a backend for gnetlist and have a minor problem, the top level schematic has IPAD/OPAD/IOPADs that i need to list in the netlist but I can't find a way to directly address the top level schematic, it doesn't seem to have a uref I can use to reference it. It does have a unique attribute and I can access it fine using 'gnetlist:get-toplevel-attribute', but I just basically need to get the pads from the top level schematic so I can list them in the netlist. I'm not quite sure what you're asking, but perhaps (gnetlist:graphical-objs-in-net-with-attrib-get-attrib) is the function you seek. Any hints? Did I miss something in the wiki? I've posted a list of primitives a few times (most recently http://archives.seul.org/geda/user/May-2011/msg00399.html), but as far as I know they haven't made it to the official documentation. 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 backend
I'm not quite sure what you're asking, but perhaps (gnetlist:graphical-objs-in-net-with-attrib-get-attrib) is the function you seek. Sorry for being unclear (one of those days at work) so let me try again... I'm using gschem for an IC design and writing a gnetlist backend to produce a particular format to feed into a global router. I have the netlisting portion working well but with the way we do the schematics (fully hierarchical) we have a top level schematic with instances (gates and modules we've designed ) with IPADS/OPADS/IOPADS to basically act as package pins. The netlist requires these PADS in the top level schematic be listed at the top of the netlist file, normally I can access pins of an instance by passing a uref to one of the gnetlist primitives (forget which one) and getting back a list of pins but I cannot do that for the very top level schematic, it seems to not have a uref or any way to say give me a list of pins that are in the top level. Or if it could do give me a list of objects that are in the top level, I could find the iopads but again I can't find a way to do that either. So I am asking if it is possible to tell gnetlist to go to the top level schematic in the hierarchy and return to me the IPADS/OPADS/IOPADS or something similar. I've posted a list of primitives a few times (most recently http://archives.seul.org/geda/user/May-2011/msg00399.html), but as far as I know they haven't made it to the official documentation. Yes, I found that a day ago and it was very helpful, appreciate you having posted it. -Frank ___ 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: gnetlist (was: Perl)
On Jun 1, 2011, at 2:05 AM, DJ Delorie wrote: Why have a core at all? One of the issues with the current gnetlist is that it cannot be ported to a different Scheme implementation, because the core is Guile-specific. Why not start from Scheme functions for reading/writing .sch format? I never said the core had to be C, but given we already have an official how to read a .sch in C, Not really. We have code to read a .sch that's tangled with other core code. it makes sense to use that library - somehow. Who's volunteering to make this usable? For the PCB case, I suspect PCB will produce a scheme script that the backend can just run to load its data. Perhaps a sch2scm helper program is in order? Can't be written using the present core, because the required raw data is inaccessible. By The Core I meant the program called gnetlist, which loads the design files and runs the backend. Even if you turn that around and have the core be some library that handles the overhead of initializing a netlister, it's still some minimum amount of overhead that needs to be done every time. Basic housekeeping - parsing the command line, loading the .config and finding the backend/library locations, reading design files, etc. - always need to be done. gnetlist's command line parsing is thoroughly encrusted with barnacles: it gets in the way more than it helps. The other stuff is scripted in Scheme, and it seems to me that it would be much cleaner and simpler if it wasn't dependent on the core C code. 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
On Jun 1, 2011, at 1:56 AM, DJ Delorie wrote: so, load the design files as raw data seems to mean so that the same input could be recreated from the internal data representation. Well, assuming we actually record *all* the data. My point was, whatever data we care about, we do the least amount of processing on, unless the backend asks for it. In the end, we care about all of the input data. There is no way to say reliably: we won't need item X. And this is the flaw of top-down design from a set of scenarios. It results in a grab-bag of features without a foundation. I didn't expect *everything* to be read in *exactly*. I expect everything to be parsed into a data structure, from which the input could be reconstructed if necessary, but which is also suitable as input to processing functions in the language. 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
On 05/30/2011 09:35 PM, John Doty wrote: On May 31, 2011, at 6:35 AM, John Griessen wrote: I'd like the first definition of what gnetlist does be, Output any data it takes in, in the same format, with lost spatial position information allowed, but keeping all other data intact. I think the reader should preserve *all* of the information in a .sch file. There are several reasons: 1. Net connectivity depends on spatial information. But one approach doesn't fit all needs here. Right now, we have a simple minded netlister that reduces the net geometry in the schematic to a netlist model in which a net is topologically a single point. But suppose we start putting attributes on net segments (this segment must carry 10A)? Shouldn't a back end for a layout tool that can handle this be able to see this, figure it out? +1 from me. Gate drive sub-circuits in power designs come to mind, as well as Kelvin connections. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist
so, load the design files as raw data seems to mean so that the same input could be recreated from the internal data representation. Well, assuming we actually record *all* the data. My point was, whatever data we care about, we do the least amount of processing on, unless the backend asks for it. I didn't expect *everything* to be read in *exactly*. You left out layout, That would be back-annotation info. In my world, PCB asks for the netlist, so it needs to figure out how to tell gnetlist what its data is. so I guess you mean reading data about physical stackup in 3D is not desirable for gnetlist. I kinda agree -- it would be hard for gnetlist to output that without a lot of physical layout code. Right, but gnetlist needs to know about, for example, pin swapping. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist (was: Perl)
Why have a core at all? One of the issues with the current gnetlist is that it cannot be ported to a different Scheme implementation, because the core is Guile-specific. Why not start from Scheme functions for reading/writing .sch format? I never said the core had to be C, but given we already have an official how to read a .sch in C, it makes sense to use that library - somehow. For the PCB case, I suspect PCB will produce a scheme script that the backend can just run to load its data. Perhaps a sch2scm helper program is in order? By The Core I meant the program called gnetlist, which loads the design files and runs the backend. Even if you turn that around and have the core be some library that handles the overhead of initializing a netlister, it's still some minimum amount of overhead that needs to be done every time. Basic housekeeping - parsing the command line, loading the .config and finding the backend/library locations, reading design files, etc. - always need to be done. This is already present, in shallow form, in gnetlist.scm and gnetlist-post.scm, but much of the digestion happens unconditionally Right. Gnetlist calls that function before running the backend, but IMHO the backend should call that function - if that's what the backend wants. I suspect a small handful of that functions would suffice for the netlisters we already have. OK, I think we now have a nice creative rivalry between Schemers and Pythonians. Let's see some code! If you wait for me to write code, it won't be in scheme :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist (was: Perl)
On 05/30/2011 01:50 AM, John Doty wrote: But who's volunteering? On 05/30/2011 01:50 AM, John Doty wrote: So, one way or another, we're looking at a new tool, I think. Maybe we keep the old gnetlist around and feed it modified/annotated schematics. There will always be people who don't like a particular choice. That's true of anything. All changing it will accomplish is changing who is pleased and who is disgusted. I'm with DJ here: contributions will decide. The language doesn't matter so much to me. The big issue here is that our tool, gnetlist, hides much of the design data behind its API. This makes general-purpose design translation tricky, and annotation impossible. So, the first challenge to the various language advocates here is to prototype a fundamental API that reveals all, in a way convenient for higher level factors to exploit. I would like to separate out some API functions and code them if it could be one day's worth at a time. I won't be able to volunteer more than a day every other week. I can see learning what's needed, getting little chunks done, then with the promise of future completion, and maybe merit badges, enlist others to help with little chunks. One problem gettingmovement on code like gEDA is tha magnitude scares away certain kinds of volunteers - they won't start something they can't see finishing, or anything that is weeks long. What does an API prototype look like? An outline? A list of paired commands and descriptions of what they do? John -- Ecosensory ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist (was: Perl)
One thought I had for gnetlist backends, is to recode gnetlist as a set of libraries. The Core would only load the design files (schematics, spreadsheets, databases, back-annotation info, etc) as raw data; the backend would be required to call at least one library function that said I want data in this format. The formats could be layered in the library, with each layer distilling the data even further, so that each backend could choose how much the data is pre-digested. Something like PCB's current backend, for example, would ask for a fully flattened design with all connectivity resolved and reduced to pin-level netlists. A Verilog backend might want busses not reduced to pin-level, or the heirarchy left intact. A BOM might not bother with connectivity, but ask for additional attribute processing. Etc. This way, we can centralize a lot of the common tasks, without forcing those decisions on the backends. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist
On 05/30/2011 11:55 AM, DJ Delorie wrote: One thought I had for gnetlist backends, is to recode gnetlist as a set of libraries. The Core would only load the design files (schematics, spreadsheets, databases, back-annotation info, etc) as raw data; the backend would be required to call at least one library function that said I want data in this format. so, load the design files as raw data seems to mean so that the same input could be recreated from the internal data representation. What does the internal data representation need to be in order to get all the kinds of data? What is a minimal definition for internal data representation that allows adding anything else in the realm of schematics, spreadsheets, databases, back-annotation info? You left out layout, so I guess you mean reading data about physical stackup in 3D is not desirable for gnetlist. I kinda agree -- it would be hard for gnetlist to output that without a lot of physical layout code. I'd like the first definition of what gnetlist does be, Output any data it takes in, in the same format, with lost spatial position information allowed, but keeping all other data intact. Can we output a schematic though? It would not have any human readability if it lost its drawing info -- its position of symbols info. We have no mechanism for outputting a layout now and are not likely to get it. It would be nice to have layout list output that is in good format for that layout tool so you could merge it with full layout files. So, is anything that asks for data in a format going to be called a back-end? And the only way to use gnetlist is with one and only one back-end, right? John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist (was: Perl)
On May 31, 2011, at 1:55 AM, DJ Delorie wrote: One thought I had for gnetlist backends, is to recode gnetlist as a set of libraries. Now you're talking. The Core would only load the design files (schematics, spreadsheets, databases, back-annotation info, etc) as raw data; the backend would be required to call at least one library function that said I want data in this format. Why have a core at all? One of the issues with the current gnetlist is that it cannot be ported to a different Scheme implementation, because the core is Guile-specific. Why not start from Scheme functions for reading/writing .sch format? The formats could be layered in the library, with each layer distilling the data even further, so that each backend could choose how much the data is pre-digested. This is already present, in shallow form, in gnetlist.scm and gnetlist-post.scm, but much of the digestion happens unconditionally in the core. The foundation for the fix for the attribute censorship bug involved just a little refactoring, to move just a tiny bit of this digestion from the core to gnetlist.scm. Something like PCB's current backend, for example, would ask for a fully flattened design with all connectivity resolved and reduced to pin-level netlists. A Verilog backend might want busses not reduced to pin-level, or the heirarchy left intact. A BOM might not bother with connectivity, but ask for additional attribute processing. Etc. This way, we can centralize a lot of the common tasks, without forcing those decisions on the backends. Yes! Put plugins and back ends in control. OK, I think we now have a nice creative rivalry between Schemers and Pythonians. Let's see some code! 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
On May 31, 2011, at 6:35 AM, John Griessen wrote: I'd like the first definition of what gnetlist does be, Output any data it takes in, in the same format, with lost spatial position information allowed, but keeping all other data intact. I think the reader should preserve *all* of the information in a .sch file. There are several reasons: 1. Net connectivity depends on spatial information. But one approach doesn't fit all needs here. Right now, we have a simple minded netlister that reduces the net geometry in the schematic to a netlist model in which a net is topologically a single point. But suppose we start putting attributes on net segments (this segment must carry 10A)? Shouldn't a back end for a layout tool that can handle this be able to see this, figure it out? 2. Some would like busses to be more than decoration. A plug-in to do this wouldn't be hard, if bus and net geometry was accessible. 3. Netlisting isn't everything. A major application of a reader/writer library will be scripts for annotating schematics, I think. It seems to me that the .sch file format is well suited to representation as S-expressions. A list of objects, each potentially attached to a list of objects, ... 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 (was: Perl)
I was thinking of how to represent all of the connections and relationships. Then thought of sqlite3, as a database of connections. a table of symbols, a table of pins This table maps the pins to a net and a symbol. a table of nets This is a rather simple database, of connections. To compensate for complexities we want to add. a table of symbol attributes, a table of pin attributes. a table of net attributes to extend the ability of buses a table of busses a table of bus taps - This would contain a bus, bus net, and the individual net. The making a net list (no busses) would be something of the sort. In pseudo code. for each net in the sql query select net from net_table do print net: for each pin and symbol in sql query select pin_number, refdes from net_table join symbol_table using symbol_id where net_table.net = net do print refdes and pin_number end loop print \n end loop aliasing nets would be similarly simple, with it's own table. that would map the nets together. Since the data structure is a sqlite3 database any programming language. The database can be held in either memory or in file. Steve On Mon, May 30, 2011 at 6:13 PM, John Doty j...@noqsi.com wrote: On May 31, 2011, at 1:55 AM, DJ Delorie wrote: One thought I had for gnetlist backends, is to recode gnetlist as a set of libraries. Now you're talking. The Core would only load the design files (schematics, spreadsheets, databases, back-annotation info, etc) as raw data; the backend would be required to call at least one library function that said I want data in this format. Why have a core at all? One of the issues with the current gnetlist is that it cannot be ported to a different Scheme implementation, because the core is Guile-specific. Why not start from Scheme functions for reading/writing .sch format? The formats could be layered in the library, with each layer distilling the data even further, so that each backend could choose how much the data is pre-digested. This is already present, in shallow form, in gnetlist.scm and gnetlist-post.scm, but much of the digestion happens unconditionally in the core. The foundation for the fix for the attribute censorship bug involved just a little refactoring, to move just a tiny bit of this digestion from the core to gnetlist.scm. Something like PCB's current backend, for example, would ask for a fully flattened design with all connectivity resolved and reduced to pin-level netlists. A Verilog backend might want busses not reduced to pin-level, or the heirarchy left intact. A BOM might not bother with connectivity, but ask for additional attribute processing. Etc. This way, we can centralize a lot of the common tasks, without forcing those decisions on the backends. Yes! Put plugins and back ends in control. OK, I think we now have a nice creative rivalry between Schemers and Pythonians. Let's see some code! 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
gEDA-user: gnetlist and flat hierarchy handling
Hello! Well, I have trouble gnetlist (and in turn gsch2pcb as well) processing project with flat or common refdefs across all schematics. That is... I have several symbols with 'source' attribute in top level schem. Each source is unique (copy), and to minimize components I autonumbered components across whole schematic (with slotting enabled). Now some sub-schematics share slotted ICs, but gnetlist doesn't quite see it that way, since it prefixes all sub-schem elements with hierarchy tag, breaking slotting. In addition, presumably global symbols as GND and Vcc are prefixed as well, so I end up with different GND net for every schematic. I presume there isn't much I can do (with current gnetlist) to avoid prefixing (without changing schematics a lot), though a flag for gnetlist or schematic attribute to prevent hierarchical prefixing would be nice. Has anyone having/had the same problem? Anyone willing to do some gnetlist hacking? I probably could patch the code, but I don't know my way around gnetlist well enough (yet). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist and flat hierarchy handling
JohnLM wrote: Now some sub-schematics share slotted ICs, but gnetlist doesn't quite see it that way, since it prefixes all sub-schem elements with hierarchy tag, breaking slotting. In addition, presumably global symbols as GND and Vcc are prefixed as well, so I end up with different GND net for every schematic. I presume there isn't much I can do (with current gnetlist) to avoid prefixing (without changing schematics a lot), though a flag for gnetlist or schematic attribute to prevent hierarchical prefixing would be nice. Some settings in $HOME/.gEDA/gnetlistrc might do the trick. Specifically: /-- (hierarchy-traversal enabled) (hierarchy-uref-mangle disabled) (hierarchy-uref-separator ) (hierarchy-netname-mangle disabled) (hierarchy-netname-separator ) (hierarchy-netattrib-mangle disabled) (hierarchy-netattrib-separator /) \-- You may check your system-gnetlistrc for more options and explanations. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist Possible attribute conflict...
Recently, a new scheme function was added to gnetlist to check for all the attribute values a set of symbols with the same refdes might have. Unfortunately, this does not play nice with my most common use case for sets of symbols: Extra symbols for power pins of opamps and the like. In this case, I'd like to have the footprint and the value defined only once. If I do so, gsch2pcb does 1) warn about possible attribute conflict Possible attribute conflict for refdes: U1 name: footprint values: (#f SO8) 2) Assign the value unknown if the instance without the attribute is located before the others in the *.sch file. This is most probably not, what I want. Please make it so, that undefined or empty attributes are ignored in the list of attribute values. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist (bug?) subcircuit symbol without pinnumbers
Hi, a few comments/questions on this weekends gnetlist experince: gnetlist via gsch2pcb complains a lot, and adds a pin U?-? on every net that connects to a specific symbol for a subcircuit (with source= attibute). The error messages are not helpful. It took a while to figure out that gnetlist is unhappy about not finding pinnumber= attibutes on the pins of that symbol. Why does a subcircuit need pin numbers? The connectivity is establisched via pinlabel= (although pinnumber= would be more intuitive, at least until we get rid of all the attribute overloading, and since pinnumber= seems to be required for unknown reasons). Why does gnetlist not tell which entity it is complaining about in its error messages? $ gnetlist --version gnetlist: unrecognized option '--version' ... oh, that is unhelpful as well, no cut'n paste from the gschem about box either. Let's see, $ dpkg -s geda | grep ^Version Version: 1:1.6.1-4 Debian sid. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Sat, 13 Nov 2010 13:07:23 + Peter TB Brett pe...@peter-b.co.uk wrote: Could you please post a bug to the bug tracker, so we don't forget about this? Sure... -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Sat, 13 Nov 2010 14:38:57 +0100 Patrick Bernaud patri...@chez.com wrote: Have you built gnetlist from release sources (tarballs) or from a git checkout? The issue with malformed attributes should have been fixed with commit 019990c. It was a release. (version 1.6.1.20100214) Thanks, Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
Hi, Levente Kovacs writes: [...] So this is it. I have other hierarchical design, which works just fine. Any help to track down the bug, or the error in the schematics would be appreciated. Could you please post the files of your project (directly to to the list or in private to the address above if you prefer)? Regards, Patrick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Sat, 13 Nov 2010 11:24:06 +0100 Patrick Bernaud patri...@chez.com wrote: Could you please post the files of your project (directly to to the list or in private to the address above if you prefer)? Ok, I solved the problem. The problem was that there was an empty value attribute attached to one of my symbol. That is bad, but gnetlist should not crash. Thanks, Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Saturday 13 November 2010 11:44:15 Levente Kovacs wrote: On Sat, 13 Nov 2010 11:24:06 +0100 Patrick Bernaud patri...@chez.com wrote: Could you please post the files of your project (directly to to the list or in private to the address above if you prefer)? Ok, I solved the problem. The problem was that there was an empty value attribute attached to one of my symbol. That is bad, but gnetlist should not crash. Could you please post a bug to the bug tracker, so we don't forget about this? Thanks, Peter ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
Levente Kovacs writes: [...] Ok, I solved the problem. The problem was that there was an empty value attribute attached to one of my symbol. That is bad, but gnetlist should not crash. Have you built gnetlist from release sources (tarballs) or from a git checkout? The issue with malformed attributes should have been fixed with commit 019990c. Patrick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist crash
Hi all, I could make gnetlist crash with the following command: gnetlist -q -g gsch2pcb -o pcb/if_card.new.pcb -m gnet-gsch2pcb-tmp.scm sch/if_card.sch sch/ps.sch backtrace: #0 __strcmp_sse2 () at ../sysdeps/x86_64/multiarch/../strcmp.S:99 #1 0x77b97bad in g_get_attrib_value_by_attrib_name () from /usr/lib/libgeda.so.38 #2 0x778c1f1c in ?? () from /usr/lib/libguile.so.17 #3 0x778c15e4 in ?? () from /usr/lib/libguile.so.17 #4 0x778c1b68 in ?? () from /usr/lib/libguile.so.17 #5 0x778c4456 in scm_eval () from /usr/lib/libguile.so.17 #6 0x77913c9f in scm_c_catch () from /usr/lib/libguile.so.17 #7 0x77b9437d in g_scm_eval_protected () from /usr/lib/libgeda.so.38 #8 0x004072d0 in ?? () #9 0x00405661 in ?? () #10 0x00407359 in ?? () #11 0x0040749e in ?? () #12 0x00404488 in ?? () #13 0x778d7dff in ?? () from /usr/lib/libguile.so.17 #14 0x778ae93a in ?? () from /usr/lib/libguile.so.17 #15 0x77913c9f in scm_c_catch () from /usr/lib/libguile.so.17 #16 0x778aedab in scm_i_with_continuation_barrier () from /usr/lib/libguile.so.17 #17 0x778aee40 in scm_c_with_continuation_barrier () from /usr/lib/libguile.so.17 #18 0x77912d04 in scm_i_with_guile_and_parent () from /usr/lib/libguile.so.17 #19 0x778d7db5 in scm_boot_guile () from /usr/lib/libguile.so.17 #20 0x00403ef3 in ?? () #21 0x77032c4d in __libc_start_main (main=value optimized out, argc=value optimized out, ubp_av=value optimized out, init=value optimized out, fini=value optimized out, rtld_fini=value optimized out, stack_end=0x7fffe478) ---Type return to continue, or q return to quit--- at libc-start.c:228 #22 0x00402839 in ?? () #23 0x7fffe478 in ?? () #24 0x001c in ?? () #25 0x000a in ?? () #26 0x7fffe732 in ?? () #27 0x7fffe744 in ?? () #28 0x7fffe747 in ?? () #29 0x7fffe74a in ?? () #30 0x7fffe753 in ?? () #31 0x7fffe756 in ?? () #32 0x7fffe76a in ?? () #33 0x7fffe76d in ?? () #34 0x7fffe783 in ?? () #35 0x7fffe793 in ?? () #36 0x in ?? () I'm on Debian testing. I can send schematics on request. gEDA/gschem version 1.6.1.20100214. Levente -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Friday 12 November 2010 23:37:18 Levente Kovacs wrote: Hi all, I could make gnetlist crash with the following command: gnetlist -q -g gsch2pcb -o pcb/if_card.new.pcb -m gnet- gsch2pcb-tmp.scm sch/if_card.sch sch/ps.sch Hi, Are you able to narrow it down to a minimal testcase at all? Also, the stack trace would be more helpful if you installed the - dbg packages for libguile and libc. I'm not sure how to do that on Debian, I'm afraid. Thanks! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Fri, 12 Nov 2010 23:53:06 + Peter TB Brett pe...@peter-b.co.uk wrote: On Friday 12 November 2010 23:37:18 Levente Kovacs wrote: Hi all, I could make gnetlist crash with the following command: gnetlist -q -g gsch2pcb -o pcb/if_card.new.pcb -m gnet- gsch2pcb-tmp.scm sch/if_card.sch sch/ps.sch Hi, Are you able to narrow it down to a minimal testcase at all? Also, the stack trace would be more helpful if you installed the - dbg packages for libguile and libc. I'm not sure how to do that on Debian, I'm afraid. Thanks! I'm trying to build gEDA from sources. I successfully installed it, but it keep searching for *.scm files in old places. When I run gnetlist I get: Invalid path [/usr/share/gEDA/bitmap] passed to bitmap-directory Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/if_card.sch] Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/ps.sch] Failed to read init scm file [/usr/share/gEDA/scheme/gnetlist.scm] Failed to read drc2 scm file [/usr/share/gEDA/scheme/gnet-drc2.scm] How can I get the system to find the /usr/local/* stuff? Thanks, Levente ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Levente Kovacs http://levente.logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist crash
On Sat, 13 Nov 2010 01:19:18 +0100 Levente Kovacs leventel...@gmail.com wrote: I'm trying to build gEDA from sources. I successfully installed it, but it keep searching for *.scm files in old places. When I run gnetlist I get: Invalid path [/usr/share/gEDA/bitmap] passed to bitmap-directory Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/if_card.sch] Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/ps.sch] Failed to read init scm file [/usr/share/gEDA/scheme/gnetlist.scm] Failed to read drc2 scm file [/usr/share/gEDA/scheme/gnet-drc2.scm] How can I get the system to find the /usr/local/* stuff? Ok, this is solved. There was some stuff left over from the former installation of gEDA. Now... back to the story. It is a hierarchical design. Now I run the following: gdb --args /usr/local/bin/gnetlist -v -g drc2 -o drc2_out.txt if_card.sch ps.sch and I get some very funny output: GNU gdb (GDB) 7.0.1-debian Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/local/bin/gnetlist...done. (gdb) run Starting program: /usr/local/bin/gnetlist -v -g drc2 -o drc2_out.txt if_card.sch ps.sch [Thread debugging using libthread_db enabled] Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/if_card.sch] Loading schematic [/home/leva/git/lbus/hardware/concentrator/if_card/sch/ps.sch] -- Verbose mode legend n : Found net C : Found component (staring to traverse component) p : Found pin (starting to traverse pin / or examining pin) P : Found end pin connection (end of this net) R : Starting to rename a net v : Found source attribute, traversing down ^ : Finished underlying source, going back up u : Found a refdes which needs to be demangle U : Found a connected_to refdes which needs to be demangle -- - Starting internal netlist creation C CpPnnPpPPpPPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnPpnnP CpnnP Cpn nP CpnnP CpnnP CpnnPpnPpnnPpnnPpnnPpnPpnnPpPPpPnPpPnPpPnPpnn nnPpPpP CpnnP CpnP CpnP CpnPpnnnPnnP CpnPpnnnPnnP CpnP CpnP CpnP CpnP CpnnP Cpnn P CpnnP CpnnP CpnnPnP CpnP CpnP CpnPpnnPnP CpnP CpnPpnPnPpnnPpnnPpnnPpnP CpnnP Cpnn P CpnnP CpnP CpnP CpnnPpnPnP CpnnP CpnPpnPpnPpnnPPnPpPPpPP CpnPpnnPn nP CpnPpnnPnnP CpnP CpnP CpnP CpnP CpnP CpnnPpnPpnPpnPpnnPnPPpPpPpnPpnPp nnPnPPpnnPpnPpnPpnPpPpPpnPpnP CpnnP CpP CpP CpnnPpnnnPPP C pnnPpnnP CpnnP CpnnPpPpnnPpnnnPPpnnP CpnP CpnP CpnP CpnP CpnP CpnP CpnnPPnnPnP nPnPPnPpnnPPnnPnPnPnPPnP CpnnPPnnPnPnPnPPnPpnnPPnnPnPnPnPPnP CpnnPPnnPnPnPnPPnP pnnPPnnPnPnPnPPnP CpnnnPPPnnPnPnPPnPpnnnPPPnnPnPnPPnP CpnnnPPPnnPnPnPPnPpnnnPPP nnPnPnPPnP CpnnnPPPnnPnPnPPnPpnnnPPPnnPnPnPPnP CpPPPnPnPnPPnP CpPPPnPnPnPPnP CpP CpnnP CpP CpnnPpPpnnPpPpnnPpPpnnPpnnPpnnPpPnPpnn nnPnPpnPpnPpnP CpnPpPnP CpnPpPnP CpnPpPnP CpnPpnnPnnP CpnP CpnP CpnP CpnP CpPnPpPnPpnnPnnPpPnPpPnPpPnPpnPpnPpnPpnPpnPpnP CpnP CpnP Cpn nP CpnnP CpnnP CpnnP CpnnnPPPnnPnPnPnPPpnnnPPPnnPnPnPnPP CpnnPPPnnPnPnPnPnPpnnPPPn nPnPnPnPnP CpP CpnP CpnP CpnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnP CpnP CpnP CpnP DONE - Starting internal netlist creation CpnnnPPnPnnPpnnnPPnP CpnnPnPnPpnnPPnP CpnnPnPnnPnP CpnnPPnPpnnPnPnnPnP CpnnnPnPpn nPnPP CpnnPPnPnPnPpnnnPnPpnnnPpnnPpnnnPnPpPnPnPnnnpnnPPnPnPnPp PPnnnPnPnP CpnnPpnnnPnP CpnnPPnPnPnPpPnPnPnnn CpnnPpnnnPnP CpnnnP pnnnP CpnnnPnPpnnPPnP CpnnPnPnP CpnnP CpnnnPPnPpnnnPPnPnnP CpnnP CpnnnP CpnnP CpnnP Cp nPpnP CpnP CpPPnPnPpnP CpPPnnnPnPnPpPnPnPnnn CpPPnnnPnPnPpnnn nPnPnPnnn C CpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpnPpn PpnPpnPpnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnP nPnPnPnPpnnPnnPnPnPnPnPpnPpnP CpnPpnPpnnPpnPpnnPpnnPpnnPpnPpnPpnPpnnPpnnPpnnPp nnPpnnPpnnPpnnPpnnPpnPpnPpnPpnPpnPpnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnnPnPnPn PnPnPpnnnPnPnPnPnPnPpnnnPnPnPnPnPnPpnnPnnPnPnPnPnPpnPpnP CpnnnPnPnPnPnPnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnnnPnPnPnPnPnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP C pnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnP CpnnPpnnPpnnPpnnPp nnPpnPpnPpnPv - Starting internal netlist creation CpnP CpnPpnnPnnPnPnP CpnP CpnnPP CpnnPnnPnnPpPPnnPpPnPnPpnnPnPnPp
Re: gEDA-user: gnetlist partslists backends
Hi, On Wed, 2010-08-04 at 13:08 +0100, Robert Spanton wrote: Can someone with push rights to gaf get Richard's gnetlist patch into mainline? It would be very useful if someone could either accept or reject this patch as it is beginning to cause problems for my organisation. Thanks, Richard ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist returns errors for wires i can't find
i have put together an 8 page schematic, and i've taken care of all of the DRC2 errors except for 4 errors relating to a pair of wires i can't find in the schematic... Checking nets with only one connection... ERROR: Net 'unnamed_net177' has no connections. ERROR: Net 'unnamed_net176' has no connections. ... Checking type of pins connected to a net... ERROR: Net unnamed_net177 is not driven. ERROR: Net unnamed_net176 is not driven. how do i find these wires? gnetlist doesn't tell me anything about where to look for them. i ran gnetlist -g geda and see my mystery wires here: unnamed_net178 : U1 D10, R75 1 unnamed_net177 : unnamed_net176 : unnamed_net175 : U1 L06, R73 2 but still no clue as to where to find them, or even which page of the schematic to look on. can i just delete the mystery wires from the netlist? if so is there any way of applying the deletion to the schematic? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist segmentation fault
Hi John, John Doty writes: [...] This is a coding error somewhere. There should be nothing wrong with an empty string as an attribute: it's a perfectly good string. No, actually, an attribute is required to have a value, see documentation (and code) for o_attrib_string_get_name_value() in libgeda/src/o_attrib.c. Regards, Patrick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist segmentation fault
Thomas Dean writes: I have an application which causes a seg fault in gnetlist. I think this can be fixed by changing the schematic. But, Segmentation fault is NEVER the proper response. Your issue is similar to bug #3032626 (a malformed attribute as Kai-Martin explained). I have proposed a patch that is under review. Thank you for the report. Regards, Patrick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist segmentation fault
On Sep 29, 2010, at 3:31 AM, Patrick Bernaud wrote: Hi John, John Doty writes: [...] This is a coding error somewhere. There should be nothing wrong with an empty string as an attribute: it's a perfectly good string. No, actually, an attribute is required to have a value, There seems to be no good design reason for this restriction: an empty string is still a perfectly good string, just as zero is a perfectly good number. see documentation Perhaps it would be better to remove this restriction from both the code and documentation. That would simplify the documentation, and possibly the code, too. (and code) for o_attrib_string_get_name_value() in libgeda/src/o_attrib.c. Regards, Patrick ___ 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 segmentation fault
No, actually, an attribute is required to have a value, There seems to be no good design reason for this restriction: an empty string is still a perfectly good string, just as zero is a perfectly good number. I agree, this caused me problems during the final phases of my last board - I wanted to leave the attribute names alone but wipe out the values for part numbers that I knew were wrong, so I could replace them later. Sometimes, I wanted to wipe them out so I could replace them *immediately* but as soon as the dialog lost focus (so I could copy text from elsewhere) it tried to close the attribute and complained. Cut and paste is horribly non-intuitive in gschem and gattrib. Specifically: * Clicking on a cell in gattrib should not do a copy * Moving the focus away from a value field in gschem's attribute editor should not attempt to save the attribute ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist segmentation fault
I have an application which causes a seg fault in gnetlist. I think
this can be fixed by changing the schematic. But, Segmentation fault
is NEVER the proper response.
# gnetlist -g geda ulf-ant.sch
Loading schematic [/usr/home/tomdean/Electronics/Spice/ulf-ant/ulf-ant.sch]
Segmentation fault (core dumped)
tomdean
ulf-ant.sch=
v 20100214 2
C 19500 47500 1 0 0 lf353-1.sym
{
T 19500 48600 5 10 1 1 0 0 1
refdes=U101A
T 19500 48400 5 10 1 1 0 0 1
device=AD797
T 19500 47500 5 10 0 0 0 0 1
slot=1
}
C 19500 42700 1 180 1 lf353-1.sym
{
T 19600 41700 5 10 1 1 180 6 1
refdes=U102A
T 19600 41400 5 10 1 1 0 0 1
device=AD797
T 19500 42700 5 10 0 0 0 0 1
slot=1
}
C 28500 45400 1 0 0 lf353-1.sym
{
T 28500 46700 5 10 1 1 0 0 1
refdes=U103A
T 28500 46500 5 10 1 1 0 0 1
device=AD797
T 28500 45400 5 10 0 0 0 0 1
slot=1
}
C 18500 47200 1 90 0 resistor-1.sym
{
T 18200 47400 5 10 1 1 90 0 1
refdes=R101
T 17700 46900 5 10 1 1 0 0 1
value=100Meg
}
C 27300 49100 1 270 1 capacitor-1.sym
{
T 27100 49200 5 10 1 1 90 2 1
refdes=C101
T 28200 49300 5 10 0 0 90 2 1
symversion=0.1
T 26800 49800 5 10 1 1 0 0 1
value=1000uf
}
C 15200 39800 1 0 0 title-B.sym
C 18500 42100 1 90 0 resistor-1.sym
{
T 18200 42300 5 10 1 1 90 0 1
refdes=R102
T 17700 43100 5 10 1 1 0 0 1
value=100Meg
}
C 26000 49100 1 270 1 resistor-1.sym
{
T 26300 49300 5 10 1 1 90 2 1
refdes=R103
T 26700 49300 5 10 1 1 90 0 1
value=10k
}
C 26000 48100 1 270 1 resistor-1.sym
{
T 26300 48300 5 10 1 1 90 2 1
refdes=R104
T 26700 48300 5 10 1 1 90 0 1
value=10k
}
C 28100 49100 1 270 1 capacitor-1.sym
{
T 27900 49200 5 10 1 1 90 2 1
refdes=C102
T 29000 49300 5 10 0 0 90 2 1
symversion=0.1
T 27800 49800 5 10 1 1 0 0 1
value=100uf
}
N 30700 5 26100 5 4
{
T 30300 50100 5 10 1 1 0 0 1
netname=Vcc
}
N 26100 49100 26100 49000 4
C 25700 48800 1 0 1 gnd-1.sym
N 26100 48100 26100 48000 4
N 27500 48000 27500 49100 4
N 29100 49100 27500 49100 4
C 20400 47200 1 180 0 resistor-1.sym
{
T 20200 46900 5 10 1 1 180 0 1
refdes=R105
T 19700 46600 5 10 1 1 0 0 1
value=27k
}
C 19400 45400 1 90 0 resistor-1.sym
{
T 19100 45600 5 10 1 1 90 0 1
refdes=R106
T 19500 45800 5 10 1 1 0 0 1
value=1k
}
C 20400 43300 1 180 0 resistor-1.sym
{
T 20100 43500 5 10 1 1 180 0 1
refdes=R107
T 19600 43600 5 10 1 1 0 0 1
value=27k
}
N 19500 47700 19300 47700 4
N 19300 47700 19300 46300 4
{
T 18900 47400 5 10 1 1 0 0 1
netname=fb1
}
N 19500 42500 19300 42500 4
N 19300 42500 19300 44200 4
{
T 18900 43100 5 10 1 1 0 0 1
netname=fb2
}
N 19300 47100 19500 47100 4
N 19300 43200 19500 43200 4
N 20500 47900 20500 47100 4
N 20500 47100 20400 47100 4
N 20400 43200 20500 43200 4
N 20500 43200 20500 42300 4
C 21600 42400 1 180 0 resistor-1.sym
{
T 21400 42100 5 10 1 1 180 0 1
refdes=R108
T 20900 41800 5 10 1 1 0 0 1
value=27k
}
C 21600 48000 1 180 0 resistor-1.sym
{
T 21400 47700 5 10 1 1 180 0 1
refdes=R109
T 20900 47400 5 10 1 1 0 0 1
value=27k
}
N 20500 47900 20700 47900 4
{
T 20400 48200 5 10 1 1 0 0 1
netname=3
}
N 20500 42300 20700 42300 4
{
T 20600 42600 5 10 1 1 0 0 1
netname=4
}
N 18400 47200 18400 43000 4
N 2 42700 2 42800 4
{
T 19700 42900 5 10 1 1 0 0 1
netname=Vdd
}
N 2 41800 2 41900 4
{
T 20200 41700 5 10 1 1 0 0 1
netname=Vcc
}
N 2 47400 2 47500 4
{
T 20200 47300 5 10 1 1 0 0 1
netname=Vdd
}
N 2 48300 2 48400 4
{
T 20100 48500 5 10 1 1 0 0 1
netname=Vcc
}
C 29400 45100 1 180 0 resistor-1.sym
{
T 29200 44800 5 10 1 1 180 0 1
refdes=R115
T 28800 44500 5 10 1 1 0 0 1
value=27k
}
N 28300 45000 28500 45000 4
N 29600 45800 29600 45000 4
N 28300 45600 28300 44700 4
N 29000 45300 29000 45400 4
{
T 29100 45200 5 10 1 1 0 0 1
netname=Vdd
}
N 29000 46200 29000 46300 4
{
T 29100 46400 5 10 1 1 0 0 1
netname=Vcc
}
N 28300 43200 28300 43800 4
{
T 28500 43200 5 10 1 1 0 0 1
netname=GND
}
C 28900 49100 1 270 1 capacitor-1.sym
{
T 28700 49200 5 10 1 1 90 2 1
refdes=C103
T 29800 49300 5 10 0 0 90 2 1
symversion=0.1
T 28800 49800 5 10 1 1 0 0 1
value=1uf
}
C 31200 45900 1 180 0 resistor-1.sym
{
T 31000 45600 5 10 1 1 180 0 1
refdes=R117
T 30500 45300 5 10 1 1 0 0 1
value=47
}
N 31200 45800 31400 45800 4
{
T 31300 45900 5 10 1 1 0 0 1
netname=Vout
}
C 29600 48800 1 0 0 vdc-1.sym
{
T 30300 49450 5 10 1 1 0 0 1
refdes=V101
T 30300 49250 5 10 1 1 0 0 1
value=DC 6V
}
C 15700 46800 1 0 0 vsin-1.sym
{
T 16400 47450 5 10 1 1 0 0 1
refdes=V102
T 16400 47250 5 10 1 1 0 0 1
value=sin 0 1e-5 1khz
}
C 15700 42300 1 0 0 vsin-1.sym
{
T 16500 42850 5 10 1 1 0 0 1
refdes=V103
T 16300 42550 5 10 1 1 0 0 1
value=sin 0 1e-5 1khz
}
N 16000 48100 19500 48100 4
{
T 16300 48200 5 10 1 1 0 0 1
netname=1
}
N 16000 48100 16000 48000 4
N 16000 42100 19500 42100 4
{
T 16400 41800 5 10 1 1 0 0 1
netname=2
}
N 16000 42100 16000 42300 4
N 16000 46800 16000 43500 4
N 16000 45600 18400 45600 4
{
T 16100 45700 5 10 1 1 0 0 1
netname=GND
}
N 29600 45000 29400 45000 4
N 29500 45800 30300 45800 4
{
T 29600 46000 5 10 1 1 0 0 1
netname=9
}
T 24300 45700 9 10 1 0 0 0 1
100 ft. Twisted Pair (CAT-5)
C
Re: gEDA-user: gnetlist segmentation fault
Thomas Dean wrote:
I have an application which causes a seg fault in gnetlist. I think
this can be fixed by changing the schematic.
The offending symbol is A103 which refers to spice-include-1.sym
The symbol contains a spurious attribute netname= with no value.
But, Segmentation fault is NEVER the proper response.
The gsch2pcb back-end does not segfault but fails with:
At least gnetlist 20030901 is required for m4-xxx options.
Looks like this is another incarnation of the infamous m4 parsing
failure, that has been haunting geda users for years now.
ulf-ant.sch=
v 20100214 2
C 19500 47500 1 0 0 lf353-1.sym
{
(...)
T 24300 45700 9 10 1 0 0 0 1
100 ft. Twisted Pair (CAT-5)
C 20500 49700 1 0 0 spice-include-1.sym
{
T 20600 50100 5 10 1 1 0 0 1
refdes=A102
T 21000 49800 5 10 1 1 0 0 1
file=ad797.cir
T 20500 49700 5 10 1 0 0 0 1
netname=
}
(...)
I guess, the = at the end of the string is the trigger. If the
attribute contains just a single letter, gnetlist is happy with the
file. How did you manage to add the empty netlist attribute? IMHO, the
attribute editor in the GUI ties to prevent empty string values.
Bottom line: The gnetlist really needs to be more fussy on the syntax.
Currently it seems to assume m4 where there isn't. In addition, m4
should fail gracefully rather than returning broken strings.
---)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: gnetlist segmentation fault
On Wed, 2010-09-29 at 01:19 +0200, kai-martin knaak wrote: I believe this started with gschem. However, I repeat, seg fault is NEVER a proper response. tomdean ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist segmentation fault
On Sep 28, 2010, at 5:19 PM, kai-martin knaak wrote: Bottom line: The gnetlist really needs to be more fussy on the syntax. Currently it seems to assume m4 where there isn't. In addition, m4 should fail gracefully rather than returning broken strings. Huh? Gnetlist has nothing to do with m4. M4's tricky relationship with pcb causes trouble, but that's pcb's problem. This is a coding error somewhere. There should be nothing wrong with an empty string as an attribute: it's a perfectly good string. 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 -g drc2 and pintype
kai-martin knaak wrote: Karl Hammar wrote: Running gnetlist -g drc2 on a schematic I get: input/output -- pwr input and output are meant to refer to signals. The DRC assumes that signals should never be connected to power lines. With analog circuits there is no strict dividing line between signal and power. So DRC should be taken with a large grain of salt on these circuits. From what I know, it's a bad idea to leave logic inputs floating, so on TTL/CMOS gates, one will tie them to GND if not used. GND is a power line, isn't it? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist -g drc2 and pintype
Tying a digital input directly to a power rail is a bit like doing a crossword puzzle in ink. You need a lot of confidence to do that in a real design. I typically use a resistor to pull them up or down. That can always be hacked, power connections can be hard to access to modify them. Rick At 09:22 AM 9/27/2010, you wrote: kai-martin knaak wrote: Karl Hammar wrote: Running gnetlist -g drc2 on a schematic I get: input/output -- pwr input and output are meant to refer to signals. The DRC assumes that signals should never be connected to power lines. With analog circuits there is no strict dividing line between signal and power. So DRC should be taken with a large grain of salt on these circuits. From what I know, it's a bad idea to leave logic inputs floating, so on TTL/CMOS gates, one will tie them to GND if not used. GND is a power line, isn't it? ___ 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: gnetlist -g drc2 and pintype
Hi Karl, El dom, 26-09-2010 a las 11:33 +0200, Karl Hammar escribió: [snip] Checking pins without the 'pintype' attribute... Checking type of pins connected to a net... WARNING: Pin(s) with pintype 'output': U2:9 are connected by net 'unnamed_net61' to pin(s) with pintype 'input/output': U1:30 WARNING: Pin(s) with pintype 'output': U2:7 are connected by net 'unnamed_net55' to pin(s) with pintype 'input/output': X1:9 WARNING: Pin(s) with pintype 'output': U3:3 are connected by net 'Vcc' to pin(s) with pintype 'input/output': Q8:A1 Q7:A1 Q6:A1 Q5:A1 ERROR: Pin(s) with pintype 'output': U3:3 are connected by net 'Vcc' to pin(s) with pintype 'power': U2:16 U1:6 U1:4 U1:18 WARNING: Pin(s) with pintype 'input/output': Q8:A1 Q7:A1 Q6:A1 Q5:A1 are connected by net 'Vcc' to pin(s) with pintype 'power': U2:16 U1:6 U1:4 U1:18 Checking unconnected pins... ERROR: Unconnected pin U2:11 [snip] Type of pins Why does it warn about output -- input/output input/output -- pwr Because drc2 can't check if an input/output pin is really an input or an output (or even both, depending on the design). It gives you warnings (not errors) about this, so you can check by your own. It tries to catch errors like connecting an output to another output, or an output to a power rail. Drc2 is not perfect, and has limitations, but it's all we have by now. The ERROR is a lm7805's output (U3:3) connected to other pins of type pwr. How do I make it accept that? There is no concept like pwr in or pwr out, so just giving it the pwr pintype should be ok. [snip] The unconnected pins can be left unconnected, how can I make it accept that? If you connect them to a special nc (no connection) symbol, drc2 will ignore them. Best regards, Carlos ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist -g drc2 and pintype
kai-martin knaak wrote: The unconnected pins can be left unconnected, how can I make it accept that? I don't know. I put my own nc.sym at pins that are deliberately not connected. This symbol contains just one pin and no net. However, DRC still complains, because the generated net is connected to only one pin. How about a special net no_net to deal with this situation? This net would be ignored for generation of the net list. Update: There are already not-connected symbols in the default library. The following symbols live in the misc department: nc-bottom-1.sym nc-top-1.sym nc-right-1.sym nc-left.sym The drc2 backend ignores them and does not throw errors, or warnings. The magic is achieved by: device=DRC_Directive value=NoConnection graphical=1 I combined this magic with the zero pin size trick John D. told about in the other thread, to get a simplified nc-symbol. http://www.gedasymbols.org/user/kai_martin_knaak/symbols/power/nc.sym ---)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: gnetlist -g drc2 and pintype
Running gnetlist -g drc2 on a schematic I get: Checking non-numbered parts... Checking duplicated references... Checking nets with only one connection... Checking pins without the 'pintype' attribute... Checking type of pins connected to a net... WARNING: Pin(s) with pintype 'output': U2:9 are connected by net 'unnamed_net61' to pin(s) with pintype 'input/output': U1:30 WARNING: Pin(s) with pintype 'output': U2:7 are connected by net 'unnamed_net55' to pin(s) with pintype 'input/output': X1:9 WARNING: Pin(s) with pintype 'output': U3:3 are connected by net 'Vcc' to pin(s) with pintype 'input/output': Q8:A1 Q7:A1 Q6:A1 Q5:A1 ERROR: Pin(s) with pintype 'output': U3:3 are connected by net 'Vcc' to pin(s) with pintype 'power': U2:16 U1:6 U1:4 U1:18 WARNING: Pin(s) with pintype 'input/output': Q8:A1 Q7:A1 Q6:A1 Q5:A1 are connected by net 'Vcc' to pin(s) with pintype 'power': U2:16 U1:6 U1:4 U1:18 Checking unconnected pins... ERROR: Unconnected pin U2:11 ERROR: Unconnected pin U2:12 ERROR: Unconnected pin U2:13 ERROR: Unconnected pin U2:14 ERROR: Unconnected pin U1:13 ERROR: Unconnected pin U1:19 ERROR: Unconnected pin U1:20 ERROR: Unconnected pin U1:22 ERROR: Unconnected pin Q8:22 ERROR: Unconnected pin Q8:12 ERROR: Unconnected pin Q7:22 ERROR: Unconnected pin Q7:12 ERROR: Unconnected pin Q6:22 ERROR: Unconnected pin Q6:12 ERROR: Unconnected pin Q5:22 Checking slots... Checking duplicated slots... Checking unused slots... Found 4 warnings. Found 16 errors. *** Type of pins Why does it warn about output -- input/output input/output -- pwr The ERROR is a lm7805's output (U3:3) connected to other pins of type pwr. How do I make it accept that? *** The unconnected pins can be left unconnected, how can I make it accept that? Regards, /Karl Hammar - Aspö Data Lilla Aspö 148 S-742 94 Östhammar Sweden +46 173 140 57 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist -g drc2 and pintype
Karl Hammar wrote: Running gnetlist -g drc2 on a schematic I get: (...) Why does it warn about output -- input/output Don't know. IMHO, this combination should be fine. input/output -- pwr input and output are meant to refer to signals. The DRC assumes that signals should never be connected to power lines. With analog circuits there is no strict dividing line between signal and power. So DRC should be taken with a large grain of salt on these circuits. The ERROR is a lm7805's output (U3:3) connected to other pins of type pwr. How do I make it accept that? Make the output pin of the LM8705 type pwr, too. The unconnected pins can be left unconnected, how can I make it accept that? I don't know. I put my own nc.sym at pins that are deliberately not connected. This symbol contains just one pin and no net. However, DRC still complains, because the generated net is connected to only one pin. How about a special net no_net to deal with this situation? This net would be ignored for generation of the net list. ---)kaimartin(--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 nc.sym Description: application/geda-symbol ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist quitting after execl call
I am extending gnetlist and I dislike scheme. To work around this I wrote a little program in C++ to do the heavy lifting and I am trying to call it from my scheme extension to gnetlist. I wrote the following function in scheme: (define magic:write_nmos_fet (lambda (w l m) (display (string-append in write_nmos_fet (number-string w) \n) ) (execl /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) (display Finished C call\n ) )) This works and calls my C++ program (called subfunction right now). The C++ program runs without problems and produces the expected output. My problem is nothing seems to run in my scheme program after calling subfunction. For example the line: (display Finished C call\n ) does not run. Nothing else appears to run after this. However there are no error messages. Does anyone have any suggestions as to why this might be? Is there a better way to be calling external programs from gnetlist? Oliver ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist quitting after execl call
On Sep 6, 2010, at 1:08 PM, Oliver King-Smith wrote: I am extending gnetlist and I dislike scheme. To work around this I wrote a little program in C++ to do the heavy lifting and I am trying to call it from my scheme extension to gnetlist. I wrote the following function in scheme: (define magic:write_nmos_fet (lambda (w l m) (display (string-append in write_nmos_fet (number-string w) \n) ) (execl /sw/share/gEDA/scheme/subfunction --m= (number-string There's your problem: (execl) is not like a call. It replaces the current process, so it should never return unless something goes wrong. Like execl() in libc. You probably want (system) or (system*). m) --w= (number-string w) --l= (number-string l) --type=nmos ) (display Finished C call\n ) )) This works and calls my C++ program (called subfunction right now). The C++ program runs without problems and produces the expected output. My problem is nothing seems to run in my scheme program after calling subfunction. For example the line: (display Finished C call\n ) does not run. Nothing else appears to run after this. However there are no error messages. Does anyone have any suggestions as to why this might be? Is there a better way to be calling external programs from gnetlist? Oliver ___ 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 quitting after execl call
John, Ah much improved. I tried using system* but now I don't seem to be getting my command line arguments. For example both (system* /sw/share/gEDA/scheme/subfunction (string-append --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) ) and (system* /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) run my C++ program and return with guile continuing, but my program sees no signs of the command line arguments. The following code barfs out (system* (string-append /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) ) with 1: 0* [magic-new small_amplifier] In /sw/share/gEDA/scheme/gnet-magic-new.scm: 816: 1 [magic:write-top-cell small_amplifier] 799: 2 (let* ((port (open-output-file #))) (display magic port) ...) 802: 3* [magic:components #output: small_amplifier.mag 12 (OUT VSS VCC ...)] 781: 4 (if (not #) (begin # #)) ... 782: 5 (begin (let # # # ...) (magic:components port #)) 783: 6* (let ((pattern #) (package #)) (display use port) ...) 788: 7* [magic:write-component M3] 762: 8 (let* ((device #)) (cond (# #) (# #) (else #))) ... 654: 9 [system* /sw/share/gEDA/scheme/subfunction --m=1 --w=30 --l=5 --type=pmos] Any suggestions? Oliver __ From: John Doty j...@noqsi.com To: gEDA user mailing list geda-user@moria.seul.org Sent: Mon, September 6, 2010 12:22:31 PM Subject: Re: gEDA-user: gnetlist quitting after execl call On Sep 6, 2010, at 1:08 PM, Oliver King-Smith wrote: I am extending gnetlist and I dislike scheme. To work around this I wrote a little program in C++ to do the heavy lifting and I am trying to call it from my scheme extension to gnetlist. I wrote the following function in scheme: (define magic:write_nmos_fet (lambda (w l m) (display (string-append in write_nmos_fet (number-string w) \n) ) (execl /sw/share/gEDA/scheme/subfunction --m= (number-string There's your problem: (execl) is not like a call. It replaces the current process, so it should never return unless something goes wrong. Like execl() in libc. You probably want (system) or (system*). m) --w= (number-string w) --l= (number-string l) --type=nmos ) (display Finished C call\n ) )) This works and calls my C++ program (called subfunction right now). The C++ program runs without problems and produces the expected output. My problem is nothing seems to run in my scheme program after calling subfunction. For example the line: (display Finished C call\n ) does not run. Nothing else appears to run after this. However there are no error messages. Does anyone have any suggestions as to why this might be? Is there a better way to be calling external programs from gnetlist? Oliver ___ geda-user mailing list [1]geda-u...@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. [3]http://www.noqsi.com/ [4]...@noqsi.com ___ geda-user mailing list [5]geda-u...@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 3. http://www.noqsi.com/ 4. mailto:j...@noqsi.com 5. mailto:geda-user@moria.seul.org 6. 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: gnetlist quitting after execl call
On Sep 6, 2010, at 2:49 PM, Oliver King-Smith wrote: John, Ah much improved. I tried using system* but now I don't seem to be getting my command line arguments. For example both (system* /sw/share/gEDA/scheme/subfunction (string-append --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) ) and (system* /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) run my C++ program and return with guile continuing, but my program sees no signs of the command line arguments. The following code barfs out (system* (string-append /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) ) with 1: 0* [magic-new small_amplifier] In /sw/share/gEDA/scheme/gnet-magic-new.scm: 816: 1 [magic:write-top-cell small_amplifier] 799: 2 (let* ((port (open-output-file #))) (display magic port) ...) 802: 3* [magic:components #output: small_amplifier.mag 12 (OUT VSS VCC ...)] 781: 4 (if (not #) (begin # #)) ... 782: 5 (begin (let # # # ...) (magic:components port #)) 783: 6* (let ((pattern #) (package #)) (display use port) ...) 788: 7* [magic:write-component M3] 762: 8 (let* ((device #)) (cond (# #) (# #) (else #))) ... 654: 9 [system* /sw/share/gEDA/scheme/subfunction --m=1 --w=30 --l=5 --type=pmos] Any suggestions? Use (system) if you want to use a single string for the whole command, or use a single string for each argument with (system*). Oliver __ From: John Doty j...@noqsi.com To: gEDA user mailing list geda-user@moria.seul.org Sent: Mon, September 6, 2010 12:22:31 PM Subject: Re: gEDA-user: gnetlist quitting after execl call On Sep 6, 2010, at 1:08 PM, Oliver King-Smith wrote: I am extending gnetlist and I dislike scheme. To work around this I wrote a little program in C++ to do the heavy lifting and I am trying to call it from my scheme extension to gnetlist. I wrote the following function in scheme: (define magic:write_nmos_fet (lambda (w l m) (display (string-append in write_nmos_fet (number-string w) \n) ) (execl /sw/share/gEDA/scheme/subfunction --m= (number-string There's your problem: (execl) is not like a call. It replaces the current process, so it should never return unless something goes wrong. Like execl() in libc. You probably want (system) or (system*). m) --w= (number-string w) --l= (number-string l) --type=nmos ) (display Finished C call\n ) )) This works and calls my C++ program (called subfunction right now). The C++ program runs without problems and produces the expected output. My problem is nothing seems to run in my scheme program after calling subfunction. For example the line: (display Finished C call\n ) does not run. Nothing else appears to run after this. However there are no error messages. Does anyone have any suggestions as to why this might be? Is there a better way to be calling external programs from gnetlist? Oliver ___ geda-user mailing list [1]geda-u...@moria.seul.org [2]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. [3]http://www.noqsi.com/ [4]...@noqsi.com ___ geda-user mailing list [5]geda-u...@moria.seul.org [6]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:geda-user@moria.seul.org 2. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 3. http://www.noqsi.com/ 4. mailto:j...@noqsi.com 5. mailto:geda-user@moria.seul.org 6. 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 quitting after execl call
Brilliant! That works Thanks, Oliver __ From: John Doty j...@noqsi.com To: gEDA user mailing list geda-user@moria.seul.org Sent: Mon, September 6, 2010 2:09:26 PM Subject: Re: gEDA-user: gnetlist quitting after execl call On Sep 6, 2010, at 2:49 PM, Oliver King-Smith wrote: John, Ah much improved. I tried using system* but now I don't seem to be getting my command line arguments. For example both (system* /sw/share/gEDA/scheme/subfunction (string-append --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) ) and (system* /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) run my C++ program and return with guile continuing, but my program sees no signs of the command line arguments. The following code barfs out (system* (string-append /sw/share/gEDA/scheme/subfunction --m= (number-string m) --w= (number-string w) --l= (number-string l) --type=nmos ) ) with 1: 0* [magic-new small_amplifier] In /sw/share/gEDA/scheme/gnet-magic-new.scm: 816: 1 [magic:write-top-cell small_amplifier] 799: 2 (let* ((port (open-output-file #))) (display magic port) ...) 802: 3* [magic:components #output: small_amplifier.mag 12 (OUT VSS VCC ...)] 781: 4 (if (not #) (begin # #)) ... 782: 5 (begin (let # # # ...) (magic:components port #)) 783: 6* (let ((pattern #) (package #)) (display use port) ...) 788: 7* [magic:write-component M3] 762: 8 (let* ((device #)) (cond (# #) (# #) (else #))) ... 654: 9 [system* /sw/share/gEDA/scheme/subfunction --m=1 --w=30 --l=5 --type=pmos] Any suggestions? Use (system) if you want to use a single string for the whole command, or use a single string for each argument with (system*). Oliver __ From: John Doty [1]...@noqsi.com To: gEDA user mailing list [2]geda-u...@moria.seul.org Sent: Mon, September 6, 2010 12:22:31 PM Subject: Re: gEDA-user: gnetlist quitting after execl call On Sep 6, 2010, at 1:08 PM, Oliver King-Smith wrote: I am extending gnetlist and I dislike scheme. To work around this I wrote a little program in C++ to do the heavy lifting and I am trying to call it from my scheme extension to gnetlist. I wrote the following function in scheme: (define magic:write_nmos_fet (lambda (w l m) (display (string-append in write_nmos_fet (number-string w) \n) ) (execl /sw/share/gEDA/scheme/subfunction --m= (number-string There's your problem: (execl) is not like a call. It replaces the current process, so it should never return unless something goes wrong. Like execl() in libc. You probably want (system) or (system*). m) --w= (number-string w) --l= (number-string l) --type=nmos ) (display Finished C call\n ) )) This works and calls my C++ program (called subfunction right now). The C++ program runs without problems and produces the expected output. My problem is nothing seems to run in my scheme program after calling subfunction. For example the line: (display Finished C call\n ) does not run. Nothing else appears to run after this. However there are no error messages. Does anyone have any suggestions as to why this might be? Is there a better way to be calling external programs from gnetlist? Oliver ___ geda-user mailing list [1][3]geda-u...@moria.seul.org [2][4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. [3][5]http://www.noqsi.com/ [4][6]...@noqsi.com ___ geda-user mailing list [5][7]geda-u...@moria.seul.org [6][8]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:[9]geda-u...@moria.seul.org 2. [10]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 3. [11]http://www.noqsi.com/ 4. mailto:[12]...@noqsi.com 5. mailto:[13]geda-u...@moria.seul.org 6. [14]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list [15]geda-u...@moria.seul.org [16]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John
Re: gEDA-user: gnetlist didn't catch duplicate hierarchical block
On Aug 24, 2010, at 7:07 PM, gene glick wrote: FYI - maybe by design? But I accidentally named 2 hierarchical blocks with the same refdes's. gnetlist -g drc2 didn't flag it either as a warning nor an error. The netlist is worked out correct, nonetheless - but maybe because I don't have any similarly named components within each block. Just good luck, in my case. Is it a bug? Is it a feature? Whatever - there it is. It's a consequence of the fact that the gnetlist front end expands hierarchy before the back end (drc2 in this case) sees the data. The majority of back ends operate on a flat view of the design, so this keeps the common case simple. You can turn this off, see http://archives.seul.org/geda/user/Nov-2008/msg00489.html. Then you can do DRC with your hierarchical blocks as components. 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: gnetlist didn't catch duplicate hierarchical block
FYI - maybe by design? But I accidentally named 2 hierarchical blocks with the same refdes's. gnetlist -g drc2 didn't flag it either as a warning nor an error. The netlist is worked out correct, nonetheless - but maybe because I don't have any similarly named components within each block. Just good luck, in my case. Is it a bug? Is it a feature? Whatever - there it is. :) gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist partslists backends
*bump* Can someone with push rights to gaf get Richard's gnetlist patch into mainline? Cheers, Rob On Thu, 2010-06-03 at 00:22 +0100, Richard Barlow wrote: Hi I discovered a bug in the partslist[1-3] backend for gnetlist when processing hierarchical designs. It strips the refdes of sub-schematic symbols from the sub-schematic components meaning you end up with duplicate refdes's. I've attached a patch which should fix this issue. To reproduce the problem: Create master schematic with symbol 'S1', attach 'source' attribute pointing to another schematic; also add a resistor 'R1'. In the other schematic add a resistor 'R1'. Run the master schematic through gnetlist with the 'partslist1' backend and there are two instances of 'R1' present. I would expect the resistor in the sub-schematic to have the refdes 'S1/R1'. Thanks Richard ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist hierarchy with pass-through
I have a hierarchical block with these names: V7 input power to block V7_RTN input power to block, return leg V5 output power from block V5_RTN output power from block , return leg within the block, V7_RTN and V5_RTN are connected - in other words, it's a pass through. At the top level, there's a net labeled V7_RTN connected to V7_RTN-PIN on block and likewise a net labeled V5_RTN connected to V5_RTN-PIN. I expected to get V7_RTN and V5_RTN connected at the top level (although not sure what name it would have taken), but the netlister does not honor the connection (looks like it makes 2 separate nets). Is this by design? gene ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist partslists backends
On Thu, 2010-06-03 at 00:22 +0100, Richard Barlow wrote: I discovered a bug in the partslist[1-3] backend for gnetlist when processing hierarchical designs. It strips the refdes of sub-schematic symbols from the sub-schematic components meaning you end up with duplicate refdes's. I've attached a patch which should fix this issue. This works for me. Cheers, Rob signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist partslists backends
Hi I discovered a bug in the partslist[1-3] backend for gnetlist when processing hierarchical designs. It strips the refdes of sub-schematic symbols from the sub-schematic components meaning you end up with duplicate refdes's. I've attached a patch which should fix this issue. To reproduce the problem: Create master schematic with symbol 'S1', attach 'source' attribute pointing to another schematic; also add a resistor 'R1'. In the other schematic add a resistor 'R1'. Run the master schematic through gnetlist with the 'partslist1' backend and there are two instances of 'R1' present. I would expect the resistor in the sub-schematic to have the refdes 'S1/R1'. Thanks Richard diff --git a/gnetlist/scheme/gnet-partslist-common.scm b/gnetlist/scheme/gnet-partslist-common.scm index 943b28e..eac539e 100644 --- a/gnetlist/scheme/gnet-partslist-common.scm +++ b/gnetlist/scheme/gnet-partslist-common.scm @@ -21,7 +21,7 @@ (let ((package (car packages))) (if (string=? (get-device package) include) (get-parts-table (cdr packages)) - (cons (list (gnetlist:get-package-attribute package refdes) + (cons (list package (get-device package) (get-value package) (gnetlist:get-package-attribute package footprint)) ;; sdb change ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist
Hi, I can't find any documentation about the hierachy support in gnetlist http://geda.seul.org/wiki/geda:gnetlist_ug#hierarchy_support Is there any documentation about hierarchy support? Is there any way to create PCAD netlist with gEDA? Thanks, Levente -- Levente Kovacs http://logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist
Is there any way to create PCAD netlist with gEDA? In the past I exported a netlist in the tango format which PCAD can import. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist
Hi Levente Kovacs, gnetlist front end(the C/SCM part) already support the non-flatten hierarchical netlist formats including BUS, such as Verilog, VHDL, Spice, GnuCap, etc., depending on the state of the gnetlist backend support. The Spice back end netlister (gnet-spice-sdb.scm) provides some support of hierarchy, although limited, but it is a good start. I had also posted several discussions and how-to over the past few years about hierarchical netlist (including BUS) generation from gnetlist backends, a Verilog specific implementation with example was provided in: http://archives.seul.org/geda/user/Jan-2009/msg00056.html (although it was coded in BASH, it can easily be done in Scheme script, Makefile, etc) However, most PCB netlists use the flat hierarchy formats, which are structurally very different from the non-flatten hierarchical formats. The good news is that since there is already enough interface information provided by the gnetlist front end to the back end (the Scheme script part) to support the non-flatten netlists (including BUS), then theoretically, there are enough informations provided by the front end to the PCB Scheme Script backends to support the flat netlist (and BUS) too. Architecturally, I would like to see the various back end netlisters to implement their back end specific parts, without impacting the overall generic interface provided by the gnetlist front end. Even if we ever decide(?) in the future to replace the current Scheme scripting language to a more modern scripting language, such as Python or Ruby, the generic interface provided by the gnetlist front end will still give us tremendous advantage to support numerous diverse back end tools and netlists. There are similar C/SCM interface provided by Python and Ruby. Some description of differences in hierarchical netlists can be found at: http://en.wikipedia.org/wiki/Netlist Best Regards, Paul Tan -Original Message- From: Levente Kovacs leventel...@gmail.com To: geda-u...@seul.org Sent: Sun, Apr 11, 2010 4:04 am Subject: gEDA-user: gnetlist Hi, I can't find any documentation about the hierachy support in gnetlist http://geda.seul.org/wiki/geda:gnetlist_ug#hierarchy_support Is there any documentation about hierarchy support? Is there any way to create PCAD netlist with gEDA? Thanks, Levente -- Levente Kovacs http://logonex.eu ___ 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: gnetlist without X?
On Thursday 11 March 2010 05:30:32 asom...@gmail.com wrote: Does anybody know if it's possible to compile gnetlist (and its dependency libgeda) without gtk? From the source, it looks like gnetlist should compile fine, but libgeda has quite a few gdk references that I would have to remove. I'm trying to use gnetlist on a headless Gentoo server, and I'd rather not have to attempt installing X. The architecture is Mips, so finding a cross-compile machine will be difficult. Would it be easier to switch to using gnetman? No, it's not currently possible to compile gEDA without X. The build system doesn't support it. (libgeda only uses GDKPixBuf for loading images embedded in schematics, and it would be relatively straightforward to add a way of disabling that functionality at compile time). The real trick's going to be persuading configure to complete. ;-) To do what you request, you'd need to patch gEDA to have a --disable-gui configure flag, probably. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist without X?
On Wed, 2010-03-10 at 22:30 -0700, asom...@gmail.com wrote: Does anybody know if it's possible to compile gnetlist (and its dependency libgeda) without gtk? From the source, it looks like gnetlist should compile fine, but libgeda has quite a few gdk references that I would have to remove. I'm trying to use gnetlist on a headless Gentoo server, and I'd rather not have to attempt installing X. The architecture is Mips, so finding a cross-compile machine will be difficult. Would it be easier to switch to using gnetman? You need the devel libraries to install, but X its-self ought not to be a requirement. gnetlist runs file with DISPLAY unset. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist without X?
Thanks for the suggests. I'll try them out tonight. Unfortunately, Gentoo has no concept of devel libraries: it's all or nothing. So I'll probably have to follow the first Peter's suggestion. -Alan On Thu, Mar 11, 2010 at 6:50 AM, Peter Clifton pc...@cam.ac.uk wrote: On Wed, 2010-03-10 at 22:30 -0700, asom...@gmail.com wrote: Does anybody know if it's possible to compile gnetlist (and its dependency libgeda) without gtk? From the source, it looks like gnetlist should compile fine, but libgeda has quite a few gdk references that I would have to remove. I'm trying to use gnetlist on a headless Gentoo server, and I'd rather not have to attempt installing X. The architecture is Mips, so finding a cross-compile machine will be difficult. Would it be easier to switch to using gnetman? You need the devel libraries to install, but X its-self ought not to be a requirement. gnetlist runs file with DISPLAY unset. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist without X?
On Thu, 2010-03-11 at 08:39 -0700, asom...@gmail.com wrote: Thanks for the suggests. I'll try them out tonight. Unfortunately, Gentoo has no concept of devel libraries: it's all or nothing. So I'll probably have to follow the first Peter's suggestion. -Alan libX11 is not X, and should not pull in a dependency on the whole X server. GTK / GDK should not either. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist without X?
Does anybody know if it's possible to compile gnetlist (and its dependency libgeda) without gtk? From the source, it looks like gnetlist should compile fine, but libgeda has quite a few gdk references that I would have to remove. I'm trying to use gnetlist on a headless Gentoo server, and I'd rather not have to attempt installing X. The architecture is Mips, so finding a cross-compile machine will be difficult. Would it be easier to switch to using gnetman? -Alan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Mon, 8 Mar 2010 20:32:01 -0300, Facundo Ferrer facundo.j.fer...@gmail.com wrote: When I ran on this server gnetlist alloc more than 95% of the RAM and at this point started to swap and when all the swap was allocated the 'top' command is not refreshed properly and I have a hard work trying to stop gnetlist. I made a second run stopping all the services and I left running on my work. Tomorrow I'll see the output but definitely there is something wrong with the netlister. Hi Facundo, I've been looking at your design, and it's making my machine fall over too. The problem appears to be that the design hits some worst-cases in gnetlists algorithms. Unfortunately, there appears to be two options: 1) Rewrite gnetlist. Unfortunately, it appears that the people who are sufficiently familiar with gnetlist to attempt this don't have much time right now. 2) Rework your schematics along the lines suggested by some of the other people on the list. For example, you could netlist each level separately to a SPICE module, and then combine them at simulation-time. Good luck! Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Tue, 2010-03-09 at 12:26 -0300, Facundo Ferrer wrote: Hi Peter, Thanks for your time. I'll try to rewrite the gnetlist but not now. I have to finish my thesis so I have to use the university provided software. If you're anything like me.. sitting down to write your thesis will make fixing gnetlist seem like a very attractive task ;) -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Hi Peter, Thanks for your time. I'll try to rewrite the gnetlist but not now. I have to finish my thesis so I have to use the university provided software. Thanks all. On Tue, Mar 9, 2010 at 6:40 AM, Peter TB Brett [1]pe...@peter-b.co.uk wrote: On Mon, 8 Mar 2010 20:32:01 -0300, Facundo Ferrer [2]facundo.j.fer...@gmail.com wrote: When I ran on this server gnetlist alloc more than 95% of the RAM and at this point started to swap and when all the swap was allocated the 'top' command is not refreshed properly and I have a hard work trying to stop gnetlist. I made a second run stopping all the services and I left running on my work. Tomorrow I'll see the output but definitely there is something wrong with the netlister. Hi Facundo, I've been looking at your design, and it's making my machine fall over too. The problem appears to be that the design hits some worst-cases in gnetlists algorithms. Unfortunately, there appears to be two options: 1) Rewrite gnetlist. Unfortunately, it appears that the people who are sufficiently familiar with gnetlist to attempt this don't have much time right now. 2) Rework your schematics along the lines suggested by some of the other people on the list. For example, you could netlist each level separately to a SPICE module, and then combine them at simulation-time. Good luck! Peter -- Peter Brett [3]pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list [4]geda-u...@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Facundo J Ferrer References 1. mailto:pe...@peter-b.co.uk 2. mailto:facundo.j.fer...@gmail.com 3. mailto:pe...@peter-b.co.uk 4. mailto:geda-user@moria.seul.org 5. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Hi again, I was on a trip so sorry for the delay. Respect for the above comments I make some tests on other hardware. My laptop hardware (1 processor): Intel Core 2 Duo P8600 Mobile processor CPU speed: 2.4 GHz FSB: 1066 MHz L2 cache: 3MB RAM: 4GB OS: Ubuntu facu...@uni-laptop:~$ uname -a Linux uni-laptop 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux Server hardware (dual processor board): Intel Xeon X5560 server processor (4 cores per processor) CPU speed: 2.8GHz Intel QPI: 6.4GT/s L3 Cache: 8MB RAM: 12GB OS: RHEL [r...@pepinillo schem]# uname -a Linux pepinillo 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux When I ran on this server gnetlist alloc more than 95% of the RAM and at this point started to swap and when all the swap was allocated the 'top' command is not refreshed properly and I have a hard work trying to stop gnetlist. I made a second run stopping all the services and I left running on my work. Tomorrow I'll see the output but definitely there is something wrong with the netlister. Thanks. On Wed, Mar 3, 2010 at 8:43 AM, John Doty [1]...@noqsi.com wrote: On Mar 1, 2010, at 1:44 AM, al davis wrote: On Sunday 28 February 2010, John Doty wrote: Ah, but it has an open interface we can use. A great strength of gEDA is that the tools play well with other tools, whether they are part of gEDA or not. I don't care how many proprietary tools you can leverage by starting the schematic on gschem. But I do. I have projects that need to get done. I do care how much of a design you can do with a 100% free/open- source flow, and how well that kind of flow works. That's ideology. But FOSS doesn't win because of ideology: it wins when it does a better job. And part of doing a better job is playing better with foreign tools. John Doty Noqsi Aerospace, Ltd. [2]http://www.noqsi.com/ [3]...@noqsi.com ___ geda-user mailing list [4]geda-u...@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Facundo J Ferrer References 1. mailto:j...@noqsi.com 2. http://www.noqsi.com/ 3. mailto:j...@noqsi.com 4. mailto:geda-user@moria.seul.org 5. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Mar 1, 2010, at 1:44 AM, al davis wrote: On Sunday 28 February 2010, John Doty wrote: Ah, but it has an open interface we can use. A great strength of gEDA is that the tools play well with other tools, whether they are part of gEDA or not. I don't care how many proprietary tools you can leverage by starting the schematic on gschem. But I do. I have projects that need to get done. I do care how much of a design you can do with a 100% free/open- source flow, and how well that kind of flow works. That's ideology. But FOSS doesn't win because of ideology: it wins when it does a better job. And part of doing a better job is playing better with foreign tools. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Sat, 27 Feb 2010 22:30:12 -0300, Facundo Ferrer facundo.j.fer...@gmail.com wrote: Hi I was working on my thesis project and I'm designing a 6-bit flash converter. The circuit has 63 comparators (made by me) , 63 inverters (made by me) and 1 decoder (126 inputs and 6 outputs, also made by me). I have a source file for each component (actually more than 127 files because the decoder has nand gates made by me). When I try to check my circuit with drc or drc2 gnetlist finished with a buffer overflow. I don't know how to solve this. Also, I tried with spice-sdb but gnetlist finish with Killed. I'll have a look at this tomorrow evening and see what I can do. Here are the links of the output: - using drc: http://pastebin.com/GrJL6pi9 - using drc2: http://pastebin.com/UnYk1f8a - using spice-sdb: http://pastebin.com/MpWjqVq8 If you need my schematics I will send you. Please e-mail me your schematics off-list. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Tue, 2010-03-02 at 12:24 +0900, timecop wrote: Please kindly use computers from this century. I'm not sure what this comment relates to, or whether it is intended to be constructive, humorous or otherwise.. Nothing I've seen suggests the machine Facundo is using is particularly old. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Tue, 2010-03-02 at 00:23 -0300, Adrian Pardini wrote: On 01/03/2010, Facundo Ferrer facundo.j.fer...@gmail.com wrote: [...] The output was quite differente in drc2 check. Now the gnetlist finish with 'Killed' instead of 'Buffer overflow' but anyway does not create the netlist (the same output for drc2 and spice-sdb backends). After that I realize that there is a 1.6.1 version (I didn't found before I think there are bad links into the web) I repeat the same steps but the problem persists. A detail that previously I didn't mention is that some times (all versions tested 1.4.3 1.6.0 1.6.1) after I ran gnetlist -gspice-sdb ... and crash with Killed my windows manager crash too and I have to reload it. That sounds a lot like the OOM killer jumped in. What do you see if you run dmesg after having gnetlist crash? This is the best hint we have yet.. I'd not thought of the OOM killer, and was about to write the WM crash off as not our problem, or perhaps bad ram. Sounds like gnetlist is really struggling with the multiple schematics - this could perhaps be an inefficiency in how the guile back-ends are written, or something similar in the core gnetlist code. As a work-around, try ensuring you have a decent amount of swap available, and expect the computer to get very slow when it is using it! Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Mar 2, 2010, at 8:29 PM, Peter Clifton wrote: Sounds like gnetlist is really struggling with the multiple schematics - this could perhaps be an inefficiency in how the guile back-ends are written, or something similar in the core gnetlist code. As someone who works with big designs in gEDA, I can tell you that gnetlist doesn't scale very well. I would at the very least expect very long run times when processing the kind of expand-hierarchy-before-gnetlist approach Facundo is taking. With more common approaches the slowdown is noticeable, but my computers have been getting faster as my gEDA designs get more ambitious, so it has never been a serious problem for me. I told Ales about this at one of the FreeDaug things years ago, and he said he wasn't surprised, but we didn't get into details. It didn't seem all that important. I believe the poor scaling is in the front end: which back end you use doesn't seem to matter. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Wed, 2010-03-03 at 06:17 +0900, John Doty wrote: I believe the poor scaling is in the front end: which back end you use doesn't seem to matter. I know there are a number of cases where the backends are badly coded, and will quickly run out the guile stack using inefficiently recursive algorithms. The fact one has to set the guile stack with (eval-options (list 'stack 20)) is a very sure sign that the backend is falling over in a _really_ bad way. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Hi again! I have the following lines in my gnetlisrc: (debug-options (list 'stack 20)) (eval-options (list 'stack 20)) Also, I tried with a bigger number and editing directly the gnet-drc2.scm but the error still appearing. Reviewing my previous flash converter (3 bits) I saw the same error but with the stack options changed in the gnetlistrc all works fine. Assuming that the drc2 backend will not report anything wrong, I tried to run the spice-sdb backend but finished unexpectedly with 'Killed'. The output and the content of the gnetlist.log: - using spice-sdb: [3][1]http://pastebin.com/MpWjqVq8 - gnetlist.log: [2]http://pastebin.com/qumXeXbu I'm using several files for each component because my thesis work is related to a fail that is injected on MOS transistors and I need to attach a voltage source in one and only one transistor at a time. I made a script that read the netlist file generated by spice-sdb backend and insert the voltage source on each transistor one per one and simulates with ngspice but now I can't make the netlist. Due this I can't have one model file for my parts (as I tried some time ago when I start with the project) because if I insert a fail (voltage source) on a model file all instances of the components using that model file will have the fail at the same time. I'm very confused. I'll keep trying. Thanks! On Sun, Feb 28, 2010 at 1:44 PM, al davis [3]ad...@freeelectron.net wrote: On Sunday 28 February 2010, John Doty wrote: Ah, but it has an open interface we can use. A great strength of gEDA is that the tools play well with other tools, whether they are part of gEDA or not. I don't care how many proprietary tools you can leverage by starting the schematic on gschem. I do care how much of a design you can do with a 100% free/open- source flow, and how well that kind of flow works. I do care about a migration path to encourage people to move from proprietary flows to free/open-source flows. I do care about cooperation between free/open-source tools, whether they are part of gEDA or not. I do care about welcoming those who are making free/open-source tools, adding to how much of a design you can do with a 100% free/open-source flow, whether they are part of gEDA or not. I do care about welcoming researchers, who are creating the new state of the art, the tools of the future. I do care about welcoming hobbyists, who are creating our culture and future. ___ geda-user mailing list [4]geda-u...@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Facundo J Ferrer References 1. http://pastebin.com/MpWjqVq8 2. http://pastebin.com/qumXeXbu 3. mailto:ad...@freeelectron.net 4. mailto:geda-user@moria.seul.org 5. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Mon, 2010-03-01 at 19:54 -0300, Facundo Ferrer wrote: Hi again! I have the following lines in my gnetlisrc: (debug-options (list 'stack 20)) (eval-options (list 'stack 20)) This is a lame thing for me to suggest, since I don't _know_ of any bug which has been fixed which might be relevant - but you're using a quite old version of gEDA / gnetlist. Could you try again with gEDA 1.6.1 ? At the very least, you might find netlisting is a little quicker, due to some fixes by Peter Brett. Let us know if you need a hand getting a later version of gEDA installed on your distro? (Let us know what distro that is, and how you got gEDA installed in the first place). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Hi, I have an Ubuntu distro: facu...@uni-laptop:~$ uname -a Linux uni-laptop 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux I have installed gEDA from the Ubuntu repos. The version is quite old: gEDA/gschem version 1.4.3.20081231 Today I downloaded the sources of version [1]1.6.0-20091004 from [2]http://www.gpleda.org/sources.html, compiled and run all again. The output was quite differente in drc2 check. Now the gnetlist finish with 'Killed' instead of 'Buffer overflow' but anyway does not create the netlist (the same output for drc2 and spice-sdb backends). After that I realize that there is a 1.6.1 version (I didn't found before I think there are bad links into the web) I repeat the same steps but the problem persists. A detail that previously I didn't mention is that some times (all versions tested 1.4.3 1.6.0 1.6.1) after I ran gnetlist -gspice-sdb ... and crash with Killed my windows manager crash too and I have to reload it. Thanks! On Mon, Mar 1, 2010 at 8:41 PM, Peter Clifton [3]pc...@cam.ac.uk wrote: On Mon, 2010-03-01 at 19:54 -0300, Facundo Ferrer wrote: Hi again! I have the following lines in my gnetlisrc: (debug-options (list 'stack 20)) (eval-options (list 'stack 20)) This is a lame thing for me to suggest, since I don't _know_ of any bug which has been fixed which might be relevant - but you're using a quite old version of gEDA / gnetlist. Could you try again with gEDA 1.6.1 ? At the very least, you might find netlisting is a little quicker, due to some fixes by Peter Brett. Let us know if you need a hand getting a later version of gEDA installed on your distro? (Let us know what distro that is, and how you got gEDA installed in the first place). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list [4]geda-u...@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Facundo J Ferrer References 1. http://geda.seul.org/release/v1.6/1.6.0/ 2. http://www.gpleda.org/sources.html 3. mailto:pc...@cam.ac.uk 4. mailto:geda-user@moria.seul.org 5. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On 01/03/2010, Facundo Ferrer facundo.j.fer...@gmail.com wrote: [...] The output was quite differente in drc2 check. Now the gnetlist finish with 'Killed' instead of 'Buffer overflow' but anyway does not create the netlist (the same output for drc2 and spice-sdb backends). After that I realize that there is a 1.6.1 version (I didn't found before I think there are bad links into the web) I repeat the same steps but the problem persists. A detail that previously I didn't mention is that some times (all versions tested 1.4.3 1.6.0 1.6.1) after I ran gnetlist -gspice-sdb ... and crash with Killed my windows manager crash too and I have to reload it. That sounds a lot like the OOM killer jumped in. What do you see if you run dmesg after having gnetlist crash? kind regards. -- Adrian. http://elesquinazotango.com.ar ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Please kindly use computers from this century. On Tue, Mar 2, 2010 at 11:14 AM, Facundo Ferrer facundo.j.fer...@gmail.com wrote: Hi, I have an Ubuntu distro: facu...@uni-laptop:~$ uname -a Linux uni-laptop 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 02:39:34 UTC 2010 x86_64 GNU/Linux I have installed gEDA from the Ubuntu repos. The version is quite old: gEDA/gschem version 1.4.3.20081231 Today I downloaded the sources of version [1]1.6.0-20091004 from [2]http://www.gpleda.org/sources.html, compiled and run all again. The output was quite differente in drc2 check. Now the gnetlist finish with 'Killed' instead of 'Buffer overflow' but anyway does not create the netlist (the same output for drc2 and spice-sdb backends). After that I realize that there is a 1.6.1 version (I didn't found before I think there are bad links into the web) I repeat the same steps but the problem persists. A detail that previously I didn't mention is that some times (all versions tested 1.4.3 1.6.0 1.6.1) after I ran gnetlist -gspice-sdb ... and crash with Killed my windows manager crash too and I have to reload it. Thanks! On Mon, Mar 1, 2010 at 8:41 PM, Peter Clifton [3]pc...@cam.ac.uk wrote: On Mon, 2010-03-01 at 19:54 -0300, Facundo Ferrer wrote: Hi again! I have the following lines in my gnetlisrc: (debug-options (list 'stack 20)) (eval-options (list 'stack 20)) This is a lame thing for me to suggest, since I don't _know_ of any bug which has been fixed which might be relevant - but you're using a quite old version of gEDA / gnetlist. Could you try again with gEDA 1.6.1 ? At the very least, you might find netlisting is a little quicker, due to some fixes by Peter Brett. Let us know if you need a hand getting a later version of gEDA installed on your distro? (Let us know what distro that is, and how you got gEDA installed in the first place). -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) ___ geda-user mailing list [4]geda-u...@moria.seul.org [5]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Facundo J Ferrer References 1. http://geda.seul.org/release/v1.6/1.6.0/ 2. http://www.gpleda.org/sources.html 3. mailto:pc...@cam.ac.uk 4. mailto:geda-user@moria.seul.org 5. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Sunday 28 February 2010, John Doty wrote: Ah, but it has an open interface we can use. A great strength of gEDA is that the tools play well with other tools, whether they are part of gEDA or not. I don't care how many proprietary tools you can leverage by starting the schematic on gschem. I do care how much of a design you can do with a 100% free/open- source flow, and how well that kind of flow works. I do care about a migration path to encourage people to move from proprietary flows to free/open-source flows. I do care about cooperation between free/open-source tools, whether they are part of gEDA or not. I do care about welcoming those who are making free/open-source tools, adding to how much of a design you can do with a 100% free/open-source flow, whether they are part of gEDA or not. I do care about welcoming researchers, who are creating the new state of the art, the tools of the future. I do care about welcoming hobbyists, who are creating our culture and future. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Hi I was working on my thesis project and I'm designing a 6-bit flash converter. The circuit has 63 comparators (made by me) , 63 inverters (made by me) and 1 decoder (126 inputs and 6 outputs, also made by me). I have a source file for each component (actually more than 127 files because the decoder has nand gates made by me). When I try to check my circuit with drc or drc2 gnetlist finished with a buffer overflow. I don't know how to solve this. Also, I tried with spice-sdb but gnetlist finish with Killed. Here are the links of the output: - using drc: [1]http://pastebin.com/GrJL6pi9 - using drc2: [2]http://pastebin.com/UnYk1f8a - using spice-sdb: [3]http://pastebin.com/MpWjqVq8 If you need my schematics I will send you. Thanks! -- Facundo J Ferrer References 1. http://pastebin.com/GrJL6pi9 2. http://pastebin.com/UnYk1f8a 3. http://pastebin.com/MpWjqVq8 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Feb 28, 2010, at 10:30 AM, Facundo Ferrer wrote: Hi I was working on my thesis project and I'm designing a 6-bit flash converter. The circuit has 63 comparators (made by me) , 63 inverters (made by me) and 1 decoder (126 inputs and 6 outputs, also made by me). I have a source file for each component (actually more than 127 files because the decoder has nand gates made by me). 127 files? That's the hard way. Should just need 63 instances of a comparator described by one file, for example. When I try to check my circuit with drc or drc2 gnetlist finished with a buffer overflow. Put the following in your gnetlistrc file: (debug-options (list 'stack 20)) (eval-options (list 'stack 20)) That should prevent overflow. Our DRC isn't really intended for this kind of circuit. I don't know how to solve this. Also, I tried with spice-sdb but gnetlist finish with Killed. Here are the links of the output: - using drc: [1]http://pastebin.com/GrJL6pi9 - using drc2: [2]http://pastebin.com/UnYk1f8a - using spice-sdb: [3]http://pastebin.com/MpWjqVq8 If you need my schematics I will send you. It looks like you're using the kind of hierarchy suitable for a printed circuit flow, not a SPICE/ASIC flow. I suggest first reading the excellent tutorial at http://www.brorson.com/gEDA/SPICE/intro.html. For ASIC, I modify Stuart's flow by leaving out the file= attributes on the symbols, preventing hierarchy expansion. I make a SPICE netlist of each subcircuit separately, and concatenate them to make the design file. That way, a 6000 transistor design needs only a 400 line netlist. A Makefile to coordinate these machinations is useful. Thanks! Good luck! It'll be fun to have another gEDA ASIC designer around. 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: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
Facundo Ferrer wrote: When I try to check my circuit with drc or drc2 gnetlist finished with a buffer overflow. I don't know how to solve this. Also, I tried with spice-sdb but gnetlist finish with Killed. Have you tried this: http://www.geda.seul.org/wiki/geda:faq-gnetlist ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Saturday 27 February 2010, John Doty wrote: It looks like you're using the kind of hierarchy suitable for a printed circuit flow, not a SPICE/ASIC flow. I suggest first reading the excellent tutorial at http://www.brorson.com/gEDA/SPICE/intro.html. Ouch .. That was written 6 years ago when things were very different than they are now. LTspice is as much not a part of gEDA as Eagle is. Promoting it here is the same as promoting Eagle. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Feb 28, 2010, at 2:17 PM, al davis wrote: On Saturday 27 February 2010, John Doty wrote: It looks like you're using the kind of hierarchy suitable for a printed circuit flow, not a SPICE/ASIC flow. I suggest first reading the excellent tutorial at http://www.brorson.com/gEDA/SPICE/intro.html. Ouch .. That was written 6 years ago when things were very different than they are now. LTspice is as much not a part of gEDA as Eagle is. Ah, but it has an open interface we can use. A great strength of gEDA is that the tools play well with other tools, whether they are part of gEDA or not. Promoting it here is the same as promoting Eagle. I don't see that document as promoting LTspice. I used it five years ago to learn Stuart's ideas on SPICE flow, but for sims I use ngspice. If you want to add gnucap-specific advice to the tutorial, I'm sure Stuart would include it. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Gnetlist, spice and probes
Hello
I like to draw simulations on gschem, along with probes, without worrying about
which net will be which
or naming them by hand.
I made small patch for spice-sdb backend for gnetlist that allows to list
special component with attribute
device=probe generates spice alike print statements.
It's a bit imperfect, because some simulation tools allow to use something
beyond V(netnumber), I even thought
about adding some attribute to probe pin to let spice-sdb:write-probe-item
fetch data directly from each pin
(in case one create multipin probe). But so far I am happy with plain voltage
ones.
gnet-spice-sdb.patch and probe.sym in attachment.
ps. please forgive me weak english, and even weaker scheme.
best regards
Maciej
--
Maciej Pijanka
--- /home/agaran/geda/share/gEDA/scheme/gnet-spice-sdb.scm 2009-11-14 20:59:47.0 +0100
+++ /home/agaran/geda/share/gEDA/scheme/gnet-spice-sdbt.scm 2010-01-15 18:56:00.0 +0100
@@ -1256,6 +1256,57 @@
)
)
+; most of this code is shamelessly copied from write-net-names-on-component
+; probably net-on-component could take one more argument that will be formater
+; which receives pin data those generated in let, etc
+; then this cruft might just provide own formater and reuse code
+(define spice-sdb:write-probe-item
+ (lambda (refdes number-of-pins port)
+(if ( number-of-pins 0)
+ (begin
+(spice-sdb:write-probe-item refdes (- number-of-pins 1) port)
+(let* ((pin-name (number-string number-of-pins))
+ (pinnumber (gnetlist:get-attribute-by-pinseq refdes pin-name pinnumber))
+ (pinseq (gnetlist:get-attribute-by-pinseq refdes pin-name pinseq))
+ (netname (car (spice-sdb:get-net refdes pinnumber)) )
+ )
+
+;; --- Super debug stuff
+ (debug-spew In write-probe-item. . . . \n)
+ (debug-spew (string-append pin-name = pin-name \n))
+ (debug-spew (string-append pinnumber = pinnumber \n))
+ (debug-spew (string-append pinseq = pinseq \n))
+ (debug-spew (string-append netname = netname \n))
+;; --
+
+ (if (not (string=? netname ERROR_INVALID_PIN))
+ (display (string-append V( netname ) ) port) ;; write out attached net if OK.
+ (debug-spew (string-append For refdes , found pin with no pinseq attribute. Ignoring. . . .\n))
+ )
+) ;; let*
+ ) ;; begin
+) ;; if
+ ) ;; lambda
+)
+
+(define spice-sdb:write-probe
+ (lambda (package port)
+;; fetch only one attr we care about, so far
+(let ((value (gnetlist:get-package-attribute package value))
+ ) ;; end of local assignments
+
+(debug-spew (string-append Found Probe item, refdes = package \n))
+
+(if (string=? value unknown)
+ (set! value TRAN))
+
+(display (string-append .print value ) port)
+(spice-sdb:write-probe-item package (length (gnetlist:get-pins package)) port)
+(newline port)
+ ) ;; end of let
+ ) ;; close of lambda
+) ;; close of define
+
;;
;; Given a refdes and number of pins, this writes out the nets
;; attached to the component's pins. This is used to write out
@@ -1617,6 +1668,8 @@
(spice-sdb:write-directive package port))
( (string=? device include)
(spice-sdb:write-include package port))
+ ( (string=? device probe)
+ (spice-sdb:write-probe package port))
( else
(spice-sdb:write-default-component package file-info-list port))
) ;; end of cond
@@ -1787,7 +1840,7 @@
;; 5. If the schematic-type is .SUBCKT: write out .ENDS, Otherwise: write out .END
;; 6. Close up the SPICE netlist file and return.
;;---
-(define spice-sdb
+(define spice-sdbt
(lambda (output-filename)
;;
;; First find out if this is a .SUBCKT lower level,
v 20091004 2
P 0 0 500 1000 1 0 0
{
T 0 0 5 10 0 0 0 0 1
pintype=io
T 855 495 5 10 0 1 0 0 1
pinlabel=probe (tran)
T 705 245 5 10 0 1 0 6 1
pinnumber=1
T 0 0 5 10 0 0 0 0 1
pinseq=1
}
L 500 1000 1200 1000 3 0 0 0 -1 -1
T 595 795 8 10 1 1 0 0 1
device=probe
T 595 1095 8 10 1 1 0 0 1
refdes=TP?
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Gnetlist, spice and probes
On Fri, 15 Jan 2010, Maciej Pijanka wrote: Hello It's a bit odd to reply to own email, but i have tweaked scheme part a bit so now it can use already existing testpoint symbol, also patch should apply without making side effect change which was in previous one from my testing. regards Maciej -- Maciej Pijanka reg. Linux user #133161 --- geda.ori/scheme/gnet-spice-sdb.scm 2009-11-14 20:59:47.0 +0100 +++ geda.mod/scheme/gnet-spice-sdb.scm 2010-01-16 01:21:09.0 +0100 @@ -1256,6 +1309,60 @@ ) ) +; most of this code is shamelessly copied from write-net-names-on-component +; probably net-on-component could take one more argument that will be formater +; which receives pin data those generated in let, etc +; then this cruft might just provide own formater and reuse code +(define spice-sdb:write-probe-item + (lambda (refdes number-of-pins port) +(if ( number-of-pins 0) + (begin +(spice-sdb:write-probe-item refdes (- number-of-pins 1) port) +(let* ((pin-name (number-string number-of-pins)) + (pinnumber (gnetlist:get-attribute-by-pinseq refdes pin-name pinnumber)) + (pinseq (gnetlist:get-attribute-by-pinseq refdes pin-name pinseq)) + (netname (car (spice-sdb:get-net refdes pinnumber)) ) + ) + +;; --- Super debug stuff + (debug-spew In write-probe-item. . . . \n) + (debug-spew (string-append pin-name = pin-name \n)) + (debug-spew (string-append pinnumber = pinnumber \n)) + (debug-spew (string-append pinseq = pinseq \n)) + (debug-spew (string-append netname = netname \n)) +;; -- + + (if (not (string=? netname ERROR_INVALID_PIN)) + (display (string-append V( netname ) ) port) ;; write out attached net if OK. + (debug-spew (string-append For refdes , found pin with no pinseq attribute. Ignoring. . . .\n)) + ) +) ;; let* + ) ;; begin +) ;; if + ) ;; lambda +) + +(define spice-sdb:write-probe + (lambda (package port) +;; fetch only one attr we care about, so far +(let ((value (gnetlist:get-package-attribute package value)) + ) ;; end of local assignments + +(debug-spew (string-append Found Probe item, refdes = package \n)) + +(if (string=? value unknown) + (set! value TRAN)) + +(display (string-append * Probe device package on nets ) port) +(spice-sdb:write-probe-item package (length (gnetlist:get-pins package)) port) +(newline port) +(display (string-append .print value +) port) +(spice-sdb:write-probe-item package (length (gnetlist:get-pins package)) port) +(newline port) + ) ;; end of let + ) ;; close of lambda +) ;; close of define + ;; ;; Given a refdes and number of pins, this writes out the nets ;; attached to the component's pins. This is used to write out @@ -1617,6 +1724,8 @@ (spice-sdb:write-directive package port)) ( (string=? device include) (spice-sdb:write-include package port)) + ( (string=? device TESTPOINT) + (spice-sdb:write-probe package port)) ( else (spice-sdb:write-default-component package file-info-list port)) ) ;; end of cond ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist + gspiceui - Paths
Hi, I made a symbol and as far as I understand it should simulate, I had to add the symbol location to the component library in gschem. However when i use gspiceui to try and simulate it gnetlist can't find the symbol (and I suppose the spice stuff) because I never told it where to look, the problem is I have read the wiki, FAQ, and all other docs I can find and nothing says what I need to do to edit the search path of gnetlist and the system-gnetlistrc even says there is a section for the path information but does not specify what would go there. Is this documented anywhere? I could probably make it work with full paths, but that just seems like a nasty hack. Thanks for any help. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist version 1.6.0 references with / are not possible
Hello, I thought it is a good idea to make an update from gEDA version 1.4.0 to the actual version 1.6.0. Sometimes I use 3pin headers with references like RS422/RS485. Unfortunately gnetlist version 1.6.0 cuts the reference in the netlist to RS485 gnetlist from older version works fine. Any reason why this will no longer support? Netnames with a / as part of name will still supported. Thomas ___ 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
On Thu, 02 Jul 2009 14:22:44 +0200 Stefan Salewski m...@ssalewski.de wrote: An other method may be a SPECIAL connection symbol in gschem for connecting nets. I think that would be a nice solution. You could then add starpoints in power and ground nets. Levente -- Levente Kovacs http://logonex.eu ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist/Scheme tutorial
Here, as promised, is the text of the first installment of my tutorial. Text only, I still gotta figure out the wiki. Comments are welcome. Don't Panic! If you've never written a program in Lisp, it looks daunting. But it's a lot easier than it looks. Wrap a little bit of syntactic sugar around Lisp, and it becomes Logo, which elementary school children can learn. And, just to make it clear what some of the funny words mean, Lisp is a computer language, Scheme is a dialect of Lisp, and Guile is an implementation of Scheme. Guile is used for scripting gEDA. In particular, the gnetlist front end, written in C, extracts topology and attribute information from schematics, and then presents that data to back end Guile scripts for processing and output. This tutorial is specifically about programming gnetlist back ends in Scheme. If you don't already know Scheme, you should probably look at other material too, such as: http://www.ccs.neu.edu/home/dorai/t-y-scheme/t-y-scheme.html Or look up Scheme tutorial with your favorite engine: there are many. The reference document at: http://www.gnu.org/software/guile/manual/html_node/index.html may also be useful. OK, let's get started. Here's a particularly simple back end: ;; gnetlist development playground (use-modules (ice-9 readline)) (activate-readline) (define (devel output-filename) (scm-style-repl) ) To use this, put it in a file called gnet-devel.scm. Copy this file to wherever gnetlist Scheme files are kept on your system. On the machine I'm using today, the command is: sudo cp gnet-devel.scm /sw/share/gEDA/scheme/ The /sw/ will be /usr/ for most Linux package installations, maybe /usr/local or ~/mygeda/ for a tarball installation. You'll have to figure that out. If the target location is writable by you without superuser privileges, you won't need the sudo. Now, translating /sw/ as needed, type: gnetlist -g devel /sw/share/gEDA/examples/lightning_detector/ lightning.sch You should see the usual gnetlist boiler plate, followed by: guile Try: guile packages You should see: (Q3 R5 Q2 R4 Q1 C6 R3 L2 A1 bat(+3v) lamp(1) R2 C5 L1 R1 C4 lamp(2) C3 C2 C1 D1 bat(0v) R7 Q4 R6) packages is a handy variable, containing a list of all unique refdes= attribute values. By typing it, you fed it to the REPL, the Read, Evaluate, Print Loop. So, the REPL read it, evaluated it (getting a list), and printed it. Now try: guile (length packages) 25 What happened here? Here, the REPL evaluated the list (length packages). In most programming languages, you'd write this expression in more traditional functional notation as length( packages ). length is a function, which tells you the length of a list. Use the same notation to do arithmetic. For example, calculate 2+3 as: guile (+ 2 3) 5 Note that the procedure + can be used to add any number of quantities, including none at all: guile (+) 0 guile (+ 1 2 3) 6 We'll make use of this later on. The readline stuff in our gnet-devel.scm back end allows you to use the cursor keys on your keyboard to move around through the history and edit input. Very handy when interacting. Try it. Another useful variable gnetlist defines is all-unique-nets (type it). Just as (length packages) tells you how many packages you have, (length all-unique-nets) will tell you how many nets you have. Then there's all-pins: guile all-pins ((1 2 3) (2 3 1) (2 1) (1 2) (1 2) (1 2) (1 2) (1 2) (1 2) (2 1) (2 1) (2 1) (1 2) (2 1) (1) (1) (2 1) (2 3 1) (2 3 1) (1) (2 1) (2 3 1) (1 2) (1) (1)) Note that this is a little more complicated than the previous examples: it's a list of lists, not just a list of strings. Each of the lists corresponds to the pins on one package. One thing we might want to extract from this is a count of the number of pins. We can't just take the length of all-pins to get this: that gives us the number of lists it contains, which is the number of packages: guile (length all-pins) 25 To get the pin count, first get the individual pin counts for each package: guile (map length all-pins) (3 3 2 2 2 2 2 2 2 2 2 2 2 2 1 1 2 3 3 1 2 3 2 1 1) This is one of the easy ways to do a loop in Scheme. (map p x) yields a list of the results of calling procedure p individually for each element of x. Then we can add them up with a slightly different kind of loop: guile (apply + (map length all-pins)) 50 (apply p x) calls procedure p once, with all of the elements of x as arguments. So the expression above winds up evaluating: (+ 3 3 2 2 2 2 2 2 2 2 2 2 2 2 1 1 2 3 3 1 2 3 2 1 1) Thus far we've been using predefined variables and procedures. We'll want to be able to define our own. It's easy: guile (define the-answer 42) guile the-answer 42 This defines a variable, the-answer, and gives it the value 42. We can also define procedures: guile (define add1 (lambda (x) (+ x 1))) guile (add1 100) 101 When you see lambda think
Re: gEDA-user: gnetlist/Scheme tutorial
On Tuesday 21 July 2009 18:45:55 John Doty wrote: Here, as promised, is the text of the first installment of my tutorial. Text only, I still gotta figure out the wiki. Comments are welcome. I would teach people the: (define (add1 x) (+ x 1)) Syntax for function definition before introducing lambda properly later. Cheers, Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist/Scheme tutorial
On Jul 21, 2009, at 2:10 PM, Peter TB Brett wrote: On Tuesday 21 July 2009 18:45:55 John Doty wrote: Here, as promised, is the text of the first installment of my tutorial. Text only, I still gotta figure out the wiki. Comments are welcome. I would teach people the: (define (add1 x) (+ x 1)) Syntax for function definition before introducing lambda properly later. I deliberately did it the other way, because I think it's easier to read. To recognize the shorthand above as a procedure definition, you have to notice the parentheses, which are the hardest thing to see because there are always so many of them. But (lambda screams procedure. And later, when the learner needs to slip local parameters into a loop (closure), (map (lambda ... will already be using familiar building blocks. One could wish that McCarthy had chosen better names for primitives. procedure, first, rest rather than lambda, car, cdr. But that's why I said: When you see lambda think procedure. Cheers, Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre ___ 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 missing features
On Wed, 2009-07-01 at 11:08 -0700, John P. Doty wrote: The question then is: what is a simple set of logical rules that should govern shorted nets? Yesterday I have seen some more connected nets in my DSO schematics -- to ensure that it will work I have replaced them now with always the same netname. This makes it more difficult to understand the schematics. I think connection of nets would be fine, and if we connect net A with net B the sum of both nets should be called something like A/B. An other method may be a SPECIAL connection symbol in gschem for connecting nets. If this is not possible we really need a warning -- I have connected nets multiple time in gschem schematics but never seen something like a warning. Best regards Stefan Salewski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnetlist missing features
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. 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
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
gEDA-user: gnetlist: netlister doesn't extract subcircuits as a subcircuit but correct refdes
Hi, I'm using gnetlist -g spice-sdb ... 1. Netlister doesn't exctract subcircuits as a subcircuits, but correct refdes instead. It puts, for example MX1/M23 instead of .subckt ... M23 .ends X1 2. netlister also doesn't correct Resistors. It is supposed that refdes will be corrected as RX1/R3, but gnetlist produces X1/R3 3. ngspice doesn't recognise MX1/M23 - it get confused with model name and treat it as a node. MX1_M23 fixes the problem, but keeping subckt sounds more reasonable against flattening netlist. Is any way to correct gnet_spice-sdb to get list subckt as a subckt? I try CVS version and 1.5.2 with the same bad results. Thanks, Alex. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnetlist: netlister doesn't extract subcircuits as a subcircuit but correct refdes
I have and am currently developing a advanced netlister called spNet that does full hierarchical netlisting plus other features. Right now I have released a version on my website that uses gnetlist as a backend but I already completed a version that is it's own netlister and does not need gnetlist but the documentation isn't full done yet. I will release a development version today that is full ready to use but will lack proper documentation. I'll reply to this post again once its released. -Anthony On Mon, Jun 22, 2009 at 1:50 AM, A.Burinskiyalexb...@gmail.com wrote: Hi, I'm using gnetlist -g spice-sdb ... 1. Netlister doesn't exctract subcircuits as a subcircuits, but correct refdes instead. It puts, for example MX1/M23 instead of .subckt ... M23 .ends X1 2. netlister also doesn't correct Resistors. It is supposed that refdes will be corrected as RX1/R3, but gnetlist produces X1/R3 3. ngspice doesn't recognise MX1/M23 - it get confused with model name and treat it as a node. MX1_M23 fixes the problem, but keeping subckt sounds more reasonable against flattening netlist. Is any way to correct gnet_spice-sdb to get list subckt as a subckt? I try CVS version and 1.5.2 with the same bad results. Thanks, Alex. ___ 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
