Re: gEDA-user: pcjc2 tessellation
On Sun, May 29, 2011 at 02:30:08PM +0100, Peter Clifton wrote: On Sun, 2011-05-29 at 11:37 +1000, Russell Shaw wrote: Hi, In _borast_bentley_ottmann_tessellate_bo_edges() which is from _cairo_bentley_ottmann_tessellate_bo_edges(), i see you deleted case CAIRO_BO_EVENT_TYPE_INTERSECTION: What effect does this have on the types of polygons that can be rasterized? Think i know now. Polygons can't have edges that cross other edges. You got it.. PCB doesn't allow self intersecting polygons, so I removed support for rendering them in an attempt to manage the complexity (and hopefully improve speed of) the tessellator. So, what happens if one directly tinkers with the PCB file with an editor or script and creates a self interscting polygon by mistake? It's not so far fetched, I sometimes edit coordinates in the file to match mechanical design. I can make a mistake or, if it is a script (which also happens), it can have a bug. Regards, Gabriel ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: pcjc2 tessellation
On Mon, 2011-05-30 at 09:37 +0200, Gabriel Paubert wrote: Think i know now. Polygons can't have edges that cross other edges. You got it.. PCB doesn't allow self intersecting polygons, so I removed support for rendering them in an attempt to manage the complexity (and hopefully improve speed of) the tessellator. So, what happens if one directly tinkers with the PCB file with an editor or script and creates a self interscting polygon by mistake? Bad things (TM). Certainly the polygon computations will give bogus results, because one of the key underlying assumptions of the polygon algebra routines is violated. If PCB is built with asserts enabled, it will just quit immediately when loading your file. It's not so far fetched, I sometimes edit coordinates in the file to match mechanical design. I can make a mistake or, if it is a script (which also happens), it can have a bug. Its not ideal, but PCB doesn't report these problems unless asserts are enabled (which makes PCB slow). We should probably add a validation pass when loading the board and refuse to display any damaged polygon. That should at least help to pick any problems up with hand (or script) edited boards sooner rather than later. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Perl
On May 29, 2011, at 12:01 AM, Dave McGuire wrote: This is my opinion, speaking as a professional developer of both hardware and software: Scheme was a good choice for gEDA, and it should be left alone. The chosen implementation of Scheme, guile, may not be the best tool for the job right now, but the language is. Abandoning Guile for this job means abandoning nearly all of the core code in gnetlist, because that's written in C, and uses Guile's FFI. That is a possible way to proceed. A rewrite of gnetlist in straight Scheme (which is certainly possible) would free us to choose a Scheme implementation. But who's volunteering? On the other hand, the totality of what we're discussing is also beyond gnetlist's capability as written. We can translate package attributes easily, but trickier mappings will be messy at best, and annotation is impossible. Given how much trouble fixing the attribute censorship bug was, refactoring the gnetlist we have now to adequately broaden its capability to allow it to address these issues seems likely to take years. 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. 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 (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
gEDA-user: guile under minipack?
Has anyone successfully built guile 1.8.7 with the latest minipack? If so, did you encouter theses errors, and how did you work around them? With no change to guile.recipe: configure:19646: checking what kind of threads to support configure:19648: result: pthreads configure:19665: checking whether pthread_attr_getstack works for the main thread configure:19672: error: cannot run test program while cross compiling If I add --with-threads=no, it complains that struct timespec is not defined. (guile 1.8.9 gives similar results) FYI I also had to add --enable-threads=win32 to gettext.recipe. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: git: quick check for new commits
On Mon, May 30, 2011 at 10:15 AM, DJ Delorie d...@delorie.com wrote: Is there a quick way to check to see if a local repo is out of date relative to a remote repo? I'd like to write a shell script that rebuilds pcb but only if something's been committed to the master repo. Rather than check out the whole tree and see if anything changed, I'd rather just compare head revisions. I tried git rev-parse but it's origin/master result is based on cached values, not actual upstream values. Perhaps I need to fetch, then rev-parse? git remote update origin would be the easiest way. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: git: quick check for new commits
git remote update origin would be the easiest way. How is this different than git fetch? Assuming the unneeded branches aren't huge. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: git: quick check for new commits
On Mon, May 30, 2011 at 1:39 PM, DJ Delorie d...@delorie.com wrote: git remote update origin would be the easiest way. How about $ git remote show origin --wpd ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Two things ... or actually, three
Op donderdag 26-05-2011 om 11:07 uur [tijdzone -0400], schreef DJ Delorie: I'd really like to contribute something back -- but as I'm not really a proficient coder Contributions come in other forms, Certainly, library work and documentation are sorely in need of contributors and even owners. If you read the light/heavy thread, you'll see I just put out a call for folks to put together sample self-contained heavy libraries, those can be as small as one component (although something big enough to be a 'starter library' would be better). OK, I'll start by reading up on the light vs. heavy symbol discussions. Do I understand correctly that heavy symbols basically have certain nets with predefined names (e.g. VCC, GND) implicitly included, whereas light symbols offer the pins to connect those nets oneself? In that case, I'm a big advocate of light symbols, because they offer maximum freedom to the designer, whereas heavy symbols would require the use of those predefined net names. Or is all this too simply put? As a new user with experience (huh?) documentation might be a good place to contribute too, pick a chunk of one of the manuals and replace it with something modern, for example. Or find an old tutorial and update it to match the current tools. That's an area where I think I can make a contribution too -- I've done a dozen or so Dummies book translations, so explaining tricky stuff in simple words is something I'm quite used to. In any event, don't feel that you have to be a code guru to help out, and don't wait for an invitation - pick something you can do and do it. - Zero length lines in PCB: I found that when drawing lines in PCB, I think you're tripping over the metric-rouding bug, where what you're seeing is lines that are 0.01 mil long. We're working on that with the metrification of PCB. Is there already some sort of script to eliminate those micro-lines? And would it be a good idea if I wrote such a script? Or is it not advisable to eliminate those lines, for reasons of connectivity? Now I was used to the work flow of gschem - [update pcb in] xgsch2pcb - PCB, but this appears to have changed. It's still available, there are now alternate ways that are more integrated, that's all. I wondered if someone could explain this in a few words. gsch2pcb, xgsch2pcb, and pcb's File-Import all do the same thing - they run gnetlist. In all three cases, *someone* needs to know which schematics are read, and which layout is updated. Um, OK ... but somehow, my older xgsch2pcb (or perhaps just the older PCB build) doesn't recognize the layout file edited with the newer PCB version any more. As a result, I haven't succeeded in updating any changes in my schematic into the newer PCB version (also see below). When I try updating the schematic now with xgsch2pcb, I get a completely new PCB window with all the elements in the upper left corner, and not the 99% completed and routed layout I have. The File-Import case is different in that the list of schematics you need, is stored in the layout that needs them, and PCB is running the process so it knows that it also needs to read the new info and update the board. Look at the documentation for the Import() action in the PCB reference, it tells you what needs to be added to the layout to store this information. I checked the PCB reference on this subject for my PCB build (http://pcb.gpleda.org/pcb-20100929/pcb.html#Import-Action ), but it isn't clear at all what I should do to import a set of schematic files (say, myproject_page1.sch, myproject_page2.sch and myproject_page3.sch, all located in ~/electronics/customer_x/techfiles/). In fact, it reads much like a manpage to a Linux newbie, but without the clarifying examples. As in: even after an hour of scrolling and browsing back and forth, I don't understand what it means, and I definitely think that I can make a contribution documentation-wise here, once I /do/ understand it ;-) When I simply choose File - Import Schematics, PCB's log shows the same response as when I press O -- it tells me the number of remaining rat lines. At this point, I'm not asked for any schematic files, changed or not. There are menu options for editing layout attributes, which is where they go. After choosing Edit - Edit attributes of - Layout I get a window with two entry fields, one containing import::src0, and one containing (null). Should I fill in a space-separated list for src0, pointing to the various schematic files? And what to do about (null), if anything? I tried entering a space-separated list with my .sch files, and subsequently the File - Import Schematics does actually offer me an opportunity to choose a (schematic?) file -- but just one, not the six I'm using in my project. After this, I can't import another one, and to tell the truth, I don't understand at all what I'm doing at this point. It sure doesn't look like I'm properly importing my
Re: gEDA-user: Two things ... or actually, three
Op donderdag 26-05-2011 om 22:56 uur [tijdzone +1000], schreef Stephen Ecob: Then two more usage questions: - Zero length lines in PCB: I found that when drawing lines in PCB, sometimes dots (zero length lines) get created inadvertently on corners and bends. This isn't much of a problem, until I start dragging lines and end points in rubber band mode: those dots then get stretched into undesired line segments which I sometimes don't notice until I get DRC errors and warnings about short circuits. Do I recall correctly that someone created a script to filter out those zero-length lines? I can't find anything in the mailing list archives, and it turns out that a regex recognizing Line[X Y X Y ... ] doesn't seem all that trivial to construct. These *may* be fixed up by Connects - Optimize routed tracks - simple optimization. Use this feature with care - it usually removes zero length lines but occasionally it also erases needed trace segments by mistake. I recommend saving first and performing DRC check and net connectivity check (o key) both before and after, checking for any changes - there /should/ be none. The trace optimizer only touches autorouted tracks by default - if you want it to work on manually routed traces you need to clear the Connects - Optimize routed tracks - [/] Only autorouted nets checkbox. Thanks for the suggestion, but it messed up the layout something wicked: over a 100 short circuits in my 1800+ nets. I'd prefer a simple script to weed out lines of 0 and 1 mil length, and I don't mind writing it myself if necessary. Anyway, thanks again, best regards, Richard Rasker ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Two things ... or actually, three
- Zero length lines in PCB: I found that when drawing lines in PCB, I think you're tripping over the metric-rouding bug, where what you're seeing is lines that are 0.01 mil long. We're working on that with the metrification of PCB. Is there already some sort of script to eliminate those micro-lines? And would it be a good idea if I wrote such a script? Or is it not advisable to eliminate those lines, for reasons of connectivity? Connects - Optimize routed tracks - simple optimization will remove micro-lines. Generally it is a good thing to do so - they are a nuisance for hand editing, and prevent the mitering optimizer from mitering corners that contain them. One thing to be careful of is that removal of micro lines that are inside a pad can cause a DRC violation. They often appear for pads that are off grid, connecting the nearest grid point to the pad center. Removal of these ones can cause a insufficient copper join overlap DRC violation. I suggest saving before trace optimizing, and also running DRC and netlist optimization before and after, and comparing results. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Two things ... or actually, three
On Tue, May 31, 2011 at 7:21 AM, Richard Rasker ras...@linetec.nl wrote: Op donderdag 26-05-2011 om 22:56 uur [tijdzone +1000], schreef Stephen Ecob: Then two more usage questions: - Zero length lines in PCB: I found that when drawing lines in PCB, sometimes dots (zero length lines) get created inadvertently on corners and bends. This isn't much of a problem, until I start dragging lines and end points in rubber band mode: those dots then get stretched into undesired line segments which I sometimes don't notice until I get DRC errors and warnings about short circuits. Do I recall correctly that someone created a script to filter out those zero-length lines? I can't find anything in the mailing list archives, and it turns out that a regex recognizing Line[X Y X Y ... ] doesn't seem all that trivial to construct. These *may* be fixed up by Connects - Optimize routed tracks - simple optimization. Use this feature with care - it usually removes zero length lines but occasionally it also erases needed trace segments by mistake. I recommend saving first and performing DRC check and net connectivity check (o key) both before and after, checking for any changes - there /should/ be none. The trace optimizer only touches autorouted tracks by default - if you want it to work on manually routed traces you need to clear the Connects - Optimize routed tracks - [/] Only autorouted nets checkbox. Thanks for the suggestion, but it messed up the layout something wicked: over a 100 short circuits in my 1800+ nets. I'd prefer a simple script to weed out lines of 0 and 1 mil length, and I don't mind writing it myself if necessary. Anyway, thanks again, best regards, Richard Rasker Oh sorry, we're writing emails at the same time! You could consider making a stripped down version of Connects - Optimize routed tracks - simple optimization. Part of if removes microlines. The code is in pcb/src/djopt.c around line 1200. Look for the text LONGEST_FRECKLE ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Two things ... or actually, three
Op vrijdag 27-05-2011 om 19:56 uur [tijdzone +0100], schreef Peter Clifton: On Thu, 2011-05-26 at 10:03 +0200, Richard Rasker wrote: - Work flow of newer gschem/PCB version: until recently, I worked with an older PCB version (20080202), but I finally got round to compiling and installing the latest version -- and it's quite an improvement (no more disappearing crosshairs, outlines and other GUI imperfections). Now I was used to the work flow of gschem - [update pcb in] xgsch2pcb - PCB, but this appears to have changed. Now I think I can find out by myself, but being a lazy person, I wondered if someone could explain this in a few words. Do I also need a newer gschem version? And has anything changed with regard to custom created symbols and footprints (as in: how do I make the new gschem and PCB versions aware of their existence?). Did you build the version from git HEAD, or a recent release? I can't quite recall when --enable-dbus became a default-on option, but if it is not switched on, then xgsch2pcb will not work. git HEAD defaults to --enable-dbus being on. I got the most recent snapshot (20100929) through http://sourceforge.net/projects/pcb/files/ It compiled OK after installing a bunch of dependencies, but I can't recall at all whether dbus was enabled or not. By the looks of it, I didn't use git, so I guess dbus is switched off. Is there a way to check if it is enabled? There is also a new File - Import Schematics option which DJ produced, which you might like to look at as an alternative to xgsch2pcb. I tried this (see another reply of mine to the mailing list), but right now, it doesn't seem all that user-friendly, to put it mildly. Best regards, Richard Rasker ___ 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: Two things ... or actually, three
The trace optimizer only touches autorouted tracks by default - if you want it to work on manually routed traces you need to clear the Connects - Optimize routed tracks - [/] Only autorouted nets checkbox. Thanks for the suggestion, but it messed up the layout something wicked: over a 100 short circuits in my 1800+ nets. I'd prefer a simple script to weed out lines of 0 and 1 mil length, and I don't mind writing it myself if necessary. One way to help the community is to file a bug report at Launchpad for this. https://launchpad.net/pcb/+bugs?field.status=Newsearch=Searchstart=0 If you are happy to share your layout with the world you can attach it to the bug report so that the developers can easily reproduce the bug. If you can't share the layout then consider stripping away most of the layout until you have a small fragment that still triggers the bug. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: guile under minipack?
On Mon, May 30, 2011 at 1:01 PM, DJ Delorie d...@delorie.com wrote: Has anyone successfully built guile 1.8.7 with the latest minipack? I just did a fresh checkout of minipack and am not even getting that far right now: pango: Build succeeded. Unpacking gtk+... patching file gdk/win32/gdkevents-win32.c Hunk #1 succeeded at 1876 (offset -367 lines). Hunk #2 succeeded at 2412 (offset -443 lines). Configuring gtk+... configure: error: *** Sorry, cups-config present but cups/cups.h missing. = gtk+: Build failed. = Anyone have any suggestions? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: guile under minipack?
On Mon, May 30, 2011 at 1:01 PM, DJ Delorie d...@delorie.com wrote: Has anyone successfully built guile 1.8.7 with the latest minipack? guile: Build succeeded. That part worked fine with the minipack I just pulled. ___ 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: Two things ... or actually, three
Richard Rasker wrote: OK, I'll start by reading up on the light vs. heavy symbol discussions. Do I understand correctly that heavy symbols basically have certain nets with predefined names (e.g. VCC, GND) implicitly included, whereas light symbols offer the pins to connect those nets oneself? Not quite. There seems to be a consensus, that hidden nets are bad style. At least, I haven't seen anyone advocate net attributes in the default lib. The main difference between heavy and light symbols is the inclusion of a footprint attribute and/or documentation links and/or simulation attributes, and/or license information. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: 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
