From exal at austin.rr.com Thu Jan 3 05:10:04 2002 From: exal at austin.rr.com (Al Arduengo) Date: Thu, 03 Jan 2002 07:10:04 -0600 Subject: [Xcircuit-dev] question about saving files Message-ID: <3C34582C.CABEC391@austin.rr.com> Hello, I am using version 2.5.2 (1) on a linux machine. I use it primarily for spice netlist generation and I am having some difficulties.I create a file with all of my subcircuit definitions and match them to symbols. However I cannot seem to figure out how to keep ALL of my work when I exit. It seems that even if I save each page individually to the same file name *and* save the library, I lose several of my subcircuits. Is it possible to have a "Save All" button so this does not keep happening? Also, I cannot seem to figure out *where* the new devices I create (from selections using 'm' to copy them) are going. The docs say it copies them to the User library but I never see a file of that name. So when I exit and restart xcircuit, nothing is ever left from my previous session. Thanks for your help. Regards, -Al Arduengo ------------ "Actual courtroom exchange: Q: Do you recall the time that you examined the body? A: The autopsy started around 8:30 p.m. Q: And Mr. Dennington was dead at the time? A: No, he was sitting on the table wondering why I was doing an autopsy." _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Thu Jan 3 06:36:59 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Thu, 03 Jan 2002 09:36:59 -0500 Subject: [Xcircuit-dev] XCircuit version 2.5.2 Message-ID: <200201031436.JAA06906@stravinsky.jhuapl.edu> Dear Al, As version 2.5.2 is "beta", it is entirely possible that some error crept into the save process, which is supposed to find all subcircuits associated with a schematic and save them. At the top of the window of "PostScript output properties" should be a checkbox labeled with the number of pages being saved. This should have the same number of pages as schematic pages in your design. If not, then something is wrong. Using "m" to make an object copies the result into the User Library, which is a space in memory, not in a disk file (the "L" key shows you all the libraries, including the User Library). Again, inclusion of user library objects into the output file should be automatic. I will try to investigate further to see if anything is wrong. You might consider not being "bleeding edge" and sticking with xcircuit version 2.3.3, as it is probably a little less error-prone. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From honeycombaudio at linuxmail.org Tue Jan 8 19:55:20 2002 From: honeycombaudio at linuxmail.org (Stephen Hughes) Date: Tue, 08 Jan 2002 22:55:20 -0500 Subject: [Xcircuit-dev] Multiple-gate chips in PCB netlists Message-ID: <200201090355.WAA20404@smtp4.gateway.net> Hello, I would like to thank all responsible for "XCircuit" and "PCB". I have taken on the challenge of creating an xcircuit library containing the entire "unique" 7400 series of ICs. Please inform me if this task has already been started by another. While working on the library I have come across a few peculiarities I thought would be of some interest. These are in reference to multiple gate chips available in xcircuit-2.5.2 and above. 1) Consider the case of the 74LS51 Dual 2-Wide 2-Input, 2-Wide 3-Input AND-OR-INVERT Gates. If you do not have your data book handy : U1-1: Two, 2-Input AND with outputs connected to a 2-Input NOR U1-2: Two, 3-Input AND with outputs connected to a 2-Input NOR I am curious as to a possible soloution to this problem. Clearly a "libinst" placed in the library file would only duplicate one of the gates. If each half of this device were created as an individual library part we would have the situation which I will describe next. 2) I placed multiple instances of the 7473 component from my 7400 library onto a page with no connections between the gates and selected "Netlist -> Write Pcb". The output was similar to that described in the tutorial: ext1 U2-2-7 ext2 U2-2-8 ext3 U2-2-9 ext4 U2-2-10 ext5 U2-2-6 ext6 U2-2-5 ext7 U1-1-14 ext8 U1-1-13 ext9 U1-1-12 ext10 U1-1-3 ext11 U1-1-2 ext12 U1-1-1 The Info pin on the device is "pcb:U parameter(1)-parameter(2)<1>". As expected the parameters were updated with an assigned value for "?" and with and index value beginning with "1". Unfortunately, the netlist clearly shows two unique devices, much the same as if I had created two parts in the library with Info pins "pcb:U parameter(1)-1" and "pcb:U parameter(1)-2". This ties in with the case of multiple but differing gates in a single IC package as in #1 above. I am assuming the ICs in this example should be labled as U1-1-"pin" and U1-2-"pin". Is the above netlist format a condition of the "PCB" program? One possible soloution would be to include the "libinst" inside the "{}" of the library object and if there is the concept of variables and scope the variable "?" would be the same within each object definition. This would solve #2. The other possible soloution would to allow multiple gate definitions within the object definition. This could perhaps use the "begingate...endgate" tags for the main object and then add "beginvirtualgate..endvirtualgate" for each instance where the gates are dissimilar in each IC package. I hope this message was informative and thought provoking. I will submit the 7400 series library file in the near future. Sincerely, Stephen Hughes, Honeycomb Electronics, Audio and Research, Inc. _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Wed Jan 9 08:59:50 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Wed, 09 Jan 2002 11:59:50 -0500 Subject: [Xcircuit-dev] 7400 series library Message-ID: <200201091659.LAA26238@stravinsky.jhuapl.edu> Dear Stephen, Thanks for the "thought-provoking" email. I hadn't even considered the case of chips containing more than one kind of gate. One (non-optimal) solution would be to make the symbol itself contain both parts. Another solution just for the 74LS51 would be to use a 3-input AND for both parts, but name the middle connection "N/C" or something; for PCB netlists, if this pin is an isolated node, it will not be connected. However, I think that generally, the proper way to deal with it is to extend the parameter substitutions to include entire substitutions of different objects. So one instance would call "and2" and one instance would call "and3". > The other possible soloution would to allow multiple gate definitions > within the object definition. This could perhaps use the > "begingate...endgate" tags for the main object and then add > "beginvirtualgate..endvirtualgate" for each instance where the gates are > dissimilar in each IC package. Object substitution would effectively do the same thing as your proposed "beginvirtualgate..endvirtualgate". At least, I think so. The chip numbering system was written before I came up with the "libinst" idea, and I was already aware of problems with the auto-numbering, which fails to work correctly under a number of situations. The condition which you related, in which you got "U1-1-" and "U2-2-", highlights one of these problems. The auto-numbering routine doesn't understand that the two parts are supposed to be the same chip. On the whole, though, there is no way to know which instances are supposed to go with which chip. If you had two 7473 chips in a circuit, it would not be clear which instances belong together. If you're doing a netlist compare or autorouting, they should permute as necessary. Otherwise, if you know which instance belongs to which chip, you can set the numbering by hand. Regardless, the auto-numbering routine needs work. This shouldn't stop you from going ahead with the 7400-series library. > One possible soloution would be to include the "libinst" inside the "{}" of > the library object and if there is the concept of variables and scope the > variable "?" would be the same within each object definition. This would > solve #2. This would still not solve the problem of determining which instances belong to which chips, for which the auto-numbering routine either needs to be told what to do, or needs to do a better job of guessing (assuming that any autorouter or netlist comparator downstream will deal with any permutations as necessary). I'll be looking forward to a 7400-series library! If you need any help, please let me know. Regards, Tim P.S.---There's still the issue of Vdd/GND pin connections. Apparently some schematic capture systems put Vdd and GND pins on each instance. At least one of the instances per chip should have explicit connections to Vdd and GND in the schematic. A PCB netlist requires these pins, to be correct. At present, connecting multiple instances to Vdd and GND will generate redundant entries in the PCB netlist, but I can get rid of that behavior. If you can think of a better method for Vdd/GND connections, though, please let me know. _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From nospamcziesler at umich.edu Sun Jan 13 13:27:44 2002 From: nospamcziesler at umich.edu (Conrad H Ziesler) Date: Sun, 13 Jan 2002 16:27:44 -0500 Subject: [Xcircuit-dev] xcircuit 2.5.1, spice netlist bug and quick patch to netlist.c Message-ID: <3C41FBD0.ADA81C53@umich.edu> problem: flat spice netlist works fine, hierarchical netlist only outputs root cell version: xcircuit-2.5.1 attatched is a hackish fix for the problem. something is wrong with the original clear_traversed routine, i can send a xcircuit file that fails if needed to reproduce the bug. --conrad -------------- next part -------------- *** xcircuit-2.5.1/netlist.c Tue Nov 20 22:08:57 2001 --- xcircuit-2.5.1-local/netlist.c Sun Jan 13 16:14:54 2002 *************** *** 2527,2532 **** --- 2527,2560 ---- #endif /* HAVE_PYTHON */ + + + + + /****************************** + this is a horrible hack. but it does fix the bug, which seems to be + some subtle problem with the existing clear_traversed routine + which seems to use a different linked list of object children instead + of the calllist. perhaps some inconsistency. + **************/ + + void hack_clear_traversed(objectptr cschem, int depth) + { + CalllistPtr calllist = cschem->calllist; + if(depth>1024) return; + + for (; calllist != NULL; calllist = calllist->next) + { + calllist->callobj->traversed=False; + hack_clear_traversed(calllist->callobj,depth+1); + } + } + /******** end of horrible hack, cziesler at umich.edu **********/ + + + + + /*----------------------------------------------------------------------*/ /* Write a netlist depending on the mode chosen */ /*----------------------------------------------------------------------*/ *************** *** 2562,2568 **** --- 2590,2609 ---- if (!strcmp(mode, "spice")) { fprintf(fp, "*SPICE circuit \"%s\" from XCircuit v%3.2f\n\n", cschem->name, version); + + + writeglobals(cschem, fp); + + /*******************************************************/ + /* bug: heir spice netlist doesn't output subckts + fix/hack: clear flags in subckts for traversal, normal routine doesn't do it correctly + author: Conrad Ziesler, cziesler at eecs.umich.edu + */ + hack_clear_traversed(cschem,0); + /*******************************************************/ + + writehierarchy(cschem, NULL, fp); } else if (!strcmp(mode, "flatspice")) { From tim at stravinsky.jhuapl.edu Sun Jan 13 19:19:14 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Sun, 13 Jan 2002 22:19:14 -0500 Subject: [Xcircuit-dev] XCircuit output error Message-ID: <200201140319.WAA00758@stravinsky.jhuapl.edu> Dear Conrad, Version 2.5.3 fixes the Spice output error. You were correct in your assessment of the bug, which has to do with clear_traversed and is also subtle; the changes required to fix it the "right" way spanned several source files, so I will just suggest that you get 2.5.3 from the xcircuit.ece.jhu.edu website. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Mon Jan 14 07:56:09 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Mon, 14 Jan 2002 10:56:09 -0500 Subject: [Xcircuit-dev] XCircuit and GTK Message-ID: <200201141556.KAA01098@stravinsky.jhuapl.edu> Dear Jeremy, > Date: Sat, 12 Jan 2002 22:03:23 -0500 (EST) > From: Jeremy T Braun > Subject: Gtk and XCircuit... > To: tim at bach.ece.jhu.edu > > a while ago I wrote to you about adding (converting?) xcircuit to Gtk > instead of Xw.. > > I've got a fair amount of free time for the rest of january with nothing > in site to do, so I was wondering if you're still interested in this? (as > I recall, you weren't sure at the time). > > Thoughts? > Jeremy I have just written a little manifesto for xcircuit, magic, PCB, gEDA, etc., outlining how they can all fit into the "ScriptEDA" idea (http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA). Read the two papers from that site first, then read my "manifesto" (which will have to be tomorrow, because I forgot to upload it yesterday). In part of the manifesto, I'm more or less committing myself to allow xcircuit to either run its own GUI, or relinquish its GUI to a controlling interpreter. This is going to require that xcircuit's GUI be carefully extracted from the rest of the program. Then, implementing another GUI should be relatively painless. The question is, is it worth doing a new GUI in Gtk, or is it better to start building the GUI in Python or Tcl, with direct calls to Tkinter or Tk? The first thing to do is to identify all of the callback functions used by the GUI, and to shred apart the xcircuit main() routine and put it back together so that it doesn't directly create any widgits itself. Then all of the GUI routines that I wrote myself, like the menu building routine "makesubmenu" and such, need to be placed in a separate source file, so they can be ignored when warranted. Most of this stuff is in "xcircuit.c", but bits and pieces have ended up spread out all over the source code (for instance, there's a single call in files.c to XwTextCopyBuffer(), which gets the contents of the selection buffer, but really ought to call an intermediate routine which hides the fact that the selection buffer capture is part of the Xw widget set). Another problem is that many of the Xw widgets are kept as global variables. The main offenders are sitting in xcircuit.c, lines 112 and 114. The main problem I see is that I don't know how compatible Gtk is with Xt---I make a lot of low-level Xt calls, and those will be MUCH harder to pull out of the code (do "grep Xt *.c" on the source directory and see what I mean). That being said, I also admit that the selfsame routines are the cause of much pain and suffering. For instance, the timer functions, implemented with XtAppAddTimeOut(), interact VERY POORLY (to say the least) with some systems, apparently a window manager problem. The WM gets the xcircuit timeout confused with the screensaver timeout, causing the whole screen to go blank when a button is pressed and occasionally causing server lockup. But that might not be a good example, because it could be replaced with the OS signal timer and bypass the X server altogether. Anyway, if that discussion hasn't put you off the idea of rewriting the XCircuit GUI, then we should start putting together something of an API which would give some kind of framework for making the core of xcircuit GUI-independent, then we can divide up the tasks that need to be done. I'm going to CC this email to the xcircuit-dev mailing list, because it is definitely more than a one-person job (else I would have done it myself by now), and it is likely more than a two-person job (any other takers?). By the way, as mentioned above, I will try to remember to upload my "ScriptEDA manifesto" tonight, and I will also post that to all the appropriate mailing lists (gEDA, magic-dev, and xcircuit-dev). As I have mentioned to others, but I don't know if it's widely known, starting next week I will be working Thursdays and Fridays from home, doing exclusively EDA programming and development related to ScriptEDA. I'm doing this as an employee of MultiGiG, Ltd., Wellingborough, England, but they are committed to the idea of "open source", so everything I do will be under GPL copyright (except for a few minor things related to their IP about fast clocking structures in VLSI hardware). My goal this time is to get essentially everybody who is doing any open-source EDA tool development on the same project without trying to restrict or redefine the development direction of any individual project (that is to say, without offending anybody). I was quite successful at pulling together the "magic development team" from disparate parts, and perhaps I have just become cocky, but I want to attempt the same thing on a grander scale. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From edadev at scsoftware.sc-software.com Tue Jan 15 14:41:53 2002 From: edadev at scsoftware.sc-software.com (John Heil) Date: Tue, 15 Jan 2002 14:41:53 -0800 (PST) Subject: [Xcircuit-dev] Dev contributions Message-ID: Hi, How do I contribute code and libraries ? I seems soureceforge is behind the web page. Thanx much John H. _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From honeycombaudio at linuxmail.org Thu Jan 10 10:20:42 2002 From: honeycombaudio at linuxmail.org (Stephen Hughes) Date: Thu, 10 Jan 2002 13:20:42 -0500 Subject: [Xcircuit-dev] RE: 7400 series library Message-ID: <200201101820.NAA04104@smtp4.gateway.net> Dear Timothy, >The chip numbering system was written before I came up with the >"libinst" idea, and I was already aware of problems with the auto-numbering, >which fails to work correctly under a number of situations. The condition >which you related, in which you got "U1-1-" and "U2-2-", highlights one of >these problems. The auto-numbering routine doesn't understand that the two >parts are supposed to be the same chip. On the whole, though, there is no >way to know which instances are supposed to go with which chip. I always find it amazing how clear the answer to my questions become only SECONDS AFTER I click the "Send" button on my e-mail client, and with no way to quickly stop the transmission. It was only then that I remembered that I needed to manually edit the U? for each instance that I placed on a schematic (as I had done for years on other systems and software). >P.S.---There's still the issue of Vdd/GND pin connections. Apparently some >schematic capture systems put Vdd and GND pins on each instance. At least >one of the instances per chip should have explicit connections to Vdd and >GND in the schematic. A PCB netlist requires these pins, to be correct. >If you can think of a better method for Vdd/GND connections, though, please >let me know. I guess a quick and dirty way to solve the issue of chips containing more than one type of gate and the issue of Vdd/GND pins would be as follows: Create the base object such as 7400-1 with no parameterized labels and include the Vdd/GND connections on this object. Next, create another base object 7400-2 with all necessary parameters and exclude the Vdd/GND connections. The remaining 2 gates in this series would be an instance of the 7400-2 object. Of course there are a few drawbacks to this as well. The first being the doubling in size of the library file. The second is the need to manually edit the .lps file to provide the correct pin numbering which excludes the Vdd/GND pins. Of course I have been manually editing the "libinst" entries in this manner anyhow. >At present, connecting multiple instances to Vdd and GND will generate >redundant entries in the PCB netlist, but I can get rid of that behavior. Perhaps this is the better way? Sincerely, Stephen Hughes Honeycomb Electronics, Audio and Research, Inc. _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From nkobzev at mail.ru Fri Jan 18 01:28:41 2002 From: nkobzev at mail.ru (Nik Kobzev) Date: Fri, 18 Jan 2002 12:28:41 +0300 Subject: [Xcircuit-dev] IBIS or SPICE import? Message-ID: Hello! Is it possible to import files in IBIS or SPICE format to XCircuit? Is there any GPL projects which support IBIS or SPICE formats? With repsect Nik. _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Mon Feb 4 12:20:45 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Mon, 04 Feb 2002 15:20:45 -0500 Subject: [Xcircuit-dev] SPICE and XCircuit Message-ID: <200202042020.PAA12871@stravinsky.jhuapl.edu> Dear Nik, There was one attempt to write a SPICE-to-xcircuit converter, by Jayant Jere. . . see http://xcircuit.ece.jhu.edu/contrib/contrib.html. However, I've never seen this program. If I have some extra time, I'll try to write one, because I think it's a very useful application. I'm not familiar with IBIS. Can you point me to any online documentation about the format? Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bryce at tlw.com Thu Feb 7 12:21:38 2002 From: bryce at tlw.com (Bryce Denney) Date: Thu, 07 Feb 2002 15:21:38 -0500 (EST) Subject: [Xcircuit-dev] autonumber causes a crash? Message-ID: I was playing with xcircuit 2.3.5 using redhat linux 6.2, and I found that it will sometimes segfault soon after autonumber components. start xcircuit 2.5.3 with no diagram press L to see the libraries click into generic click diode place the diode in the diagram select Netlist:Autonumber components use the middle button to drag a box around the gate to select it. segmentation fault It's not specific to diode--it happens on every gate I've tried. But if you select it by clicking the middle button it's ok. I'll get you a stack trace if you have any trouble reproducing this. Thanks, Bryce _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From marcelohruiz at speedy.com.ar Sun Feb 10 07:14:52 2002 From: marcelohruiz at speedy.com.ar (Marcelo H. Ruiz) Date: Sun, 10 Feb 2002 12:14:52 -0300 Subject: [Xcircuit-dev] Xcircuit for Mac OS X Message-ID: Hello! Does exist a version of xciruit for Mac OS X? Where can I download it? Thank you! Marcelo Hern?n Ruiz marcelohruiz at speedy.com.ar changomarcelo at hotmail.com ICQ 47712987 Visit? www.webabierta.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencircuitdesign.com/pipermail/xcircuit-dev/attachments/20020210/3642fb35/attachment.html From bryce at tlw.com Fri Feb 15 11:14:30 2002 From: bryce at tlw.com (Bryce Denney) Date: Fri, 15 Feb 2002 14:14:30 -0500 (EST) Subject: [Xcircuit-dev] pcb library Message-ID: I'm getting ready to make an xcircuit library of common pcb parts, and the first on my list is headers: 1x2, 1x4, 1x6, 2x2, etc. The only question is what pin numbering scheme to use for dual row headers. Is there any kind of standard for this? Does anybody have a preference? a) 09 10 11 12 13 14 15 16 01 02 03 04 05 06 07 08 b) 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 c) 02 04 06 08 10 12 14 16 01 03 05 07 09 11 13 15 d) 01 03 05 07 09 11 13 15 02 04 06 08 10 12 14 16 IMHO, c and d make sense if you're using IDC connectors to ribbon cable, but otherwise a&b are more intuitive. No, I don't want to make one for every possible combination. :) I'll also be making a matching layout symbol for all these parts, using pcb for linux. I haven't figured out how to make a library in pcb, yet. Please let me know if anyone else is working on this, or is interested in working on it with me. Regards, Bryce _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bryce at tlw.com Fri Feb 15 14:57:05 2002 From: bryce at tlw.com (Bryce Denney) Date: Fri, 15 Feb 2002 17:57:05 -0500 (EST) Subject: [Xcircuit-dev] 74xx DIP library In-Reply-To: Message-ID: I just posted xcircuit libraries for all 74xx series chips on Source Forge. They're generated by a perl script so they're not all beautiful, but it sure beats typing them in. The info is based on a library from from the sources of pcb for linux. https://sourceforge.net/tracker/index.php?func=detail&aid=518207&group_id=4952&atid=304952 Bryce _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bpaddock at csonline.net Sun Feb 17 04:18:54 2002 From: bpaddock at csonline.net (Bob Paddock) Date: Sun, 17 Feb 2002 07:18:54 -0500 Subject: [Xcircuit-dev] What shoud 'test.py' do? Message-ID: <200202170724875.SM00208@there> I'm running Mandrake 8.1, I tried running test.py, but I'm thinking I don't have some thing installed right. When I execute the script 'test.py' I get this: Traceback (most recent call last): File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ? from math import pi,sin,cos ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: PyExc_OverflowError Traceback (most recent call last): File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ? from math import pi,sin,cos ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: PyExc_OverflowError Traceback (most recent call last): File "../../../../BUILD/xcircuit-2.5.3/examples/test.py", line 7, in ? from math import pi,sin,cos ImportError: /usr/local/lib/python2.1/lib-dynload/math.so: undefined symbol: PyExc_OverflowError _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bpaddock at csonline.net Sun Feb 17 04:23:28 2002 From: bpaddock at csonline.net (Bob Paddock) Date: Sun, 17 Feb 2002 07:23:28 -0500 Subject: [Xcircuit-dev] Loading Pyton modules at start up? Message-ID: <20020217072493.SM00208@there> I know I must be over looking some thing that is staring me in the face, but after poking around the docs and source for the last hour I can't find it. How do I get the python modules like 'pagebox.py' to be loaded when I startup XCircuit automatically? Doing F)ile/Execute Script each time is getting old... _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bpaddock at csonline.net Sun Feb 17 04:45:23 2002 From: bpaddock at csonline.net (Bob Paddock) Date: Sun, 17 Feb 2002 07:45:23 -0500 Subject: [Xcircuit-dev] panzooming in the libraries? Message-ID: <200202170800296.SM00208@there> I think the 'panzoom.py' feature is a good one that I would like to use by default. Alas it seems that it only works at the schematic level. Zoom In/Zoom Out stops working at all at the library level, 'L'. :-( _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From narciso-ma at us.es Tue Feb 26 12:45:14 2002 From: narciso-ma at us.es (Narciso Moreno) Date: Tue, 26 Feb 2002 21:45:14 +0100 Subject: [Xcircuit-dev] help please! Message-ID: <3C7BF3DA.E9A18F00@us.es> Hi, I've tried Xcircuit 2.2.0 for windows in windows 95 with xwinpro and xwin32 and it works perfectly. It's a great package. But I have windows 98 at the University, and I found that it reports an error message like this: "RXVT causes a page fault in module KERNEL32.DLL". I have this message with both Xservers. Otherwise, I wanted to try the other option under VNC. I've installed that, but I don't know how to work with XCircuit under VNC. I would be gratefull if you could help me, because I haven't found a program which produces a high quality ps circuit like that. Thank you in advance. Narciso Moreno. -- Narciso Moreno Alfonso Dpto. Ingenieria Electrica Escuela Universitaria Politecnica c/Virgen de Africa, 7 41011 Sevilla (Spain) Tel.: +34 95 455 6980 Fax.: +34 95 428 2777 E-mail: narciso-ma at us.es ------------------------------------------- Trabaja como si no necesitases el dinero. Ama como si nunca hubieses sido herido. Baila como si nadie te observase. Canta como si nadie estuviese escuchando. Vive como si el Cielo fuera la Tierra. _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Wed Feb 27 08:25:21 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Wed, 27 Feb 2002 11:25:21 -0500 Subject: [Xcircuit-dev] blobs and entities Message-ID: <200202271625.LAA06787@stravinsky.jhuapl.edu> Dear Bob, > Actually a double indexed normal array might work. > "part[entity][blob]={x/y,pins}" > kind of thing. You can now rename/renumber the entities > because they are independent of the blob/pin info. That makes sense. I think the way to handle that is to expand on the "infolabel" so that an object can be declared to belong to a specific entity without assigning it a part number. It would probably be a good idea to start standardizing the methods used by the "infolabel", as this is where all the bookkeeping happens. But the general idea is that you would have "pcb:U-" which declares actual part numbers, but also "pcb:entity[]" which declares the object as belonging to a particular chip, or entity. If is changed in this object, it will be similarly changed in all objects having the same . When you grab one "quad part" component from the library, you will get all four transferred to the page, and all of them automatically assigned the same . More bookkeeping can be dealt with by "pcb:parts[DIP7400-1,DIP7400-2,DIP7400-3,DIP7400-4]" "pcb:pin[7]=GND" "pcb:pin[14]=Vdd" The first one declares that there are four parts to the entity, so that any missing parts can be added to the PCB netlist output as unconnected entities. The parts are listed by name, so that they don't have to be the same, as in your relay example. Because my "libinst" parts all have the same name, I have to think more about how the "-1", "-2", etc., should be specified both in the infolabel and in the library part name. The last two deal with the Vdd and GND pins, or any other pins not belonging to any of the parts themselves. The netlist generator would know to generate a netlist entry for only one of these per entity. I'm making up syntax as I go along, which is why I say I should be "standardizing the methods". But regardless, do these ideas seem to you like a good way of implementing multi-part entities? Any ideas you have on syntax? Standards would probably require something like: "pcb1:entityname=U" "pcb2:entityparts[DIP7400-1,DIP7400-2,DIP7400-3,DIP7400-4]" "pcb3:entity=" "pcb4:part=" "pcb5:subpart=" "pcb6:pin[7]=GND" "pcb7:pin[14]=Vdd" Warnings will pop up if you do something inconsistent, like a duplicated part or subpart. Otherwise you would be free to show unused parts on the schematic, or not, as you please, and you're free to (re)number the part or let auto-numbering do its thing. Since this involves standards and opinions, I'll CC this email to the xcircuit-dev mailing list so anybody listening in can weigh in on the issue. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bpaddock at csonline.net Tue Mar 5 15:29:22 2002 From: bpaddock at csonline.net (Bob Paddock) Date: Tue, 05 Mar 2002 18:29:22 -0500 Subject: [Xcircuit-dev] Libraries needed Message-ID: <200203051829531.SM00549@there> Any one have a good looking "Danger High Voltage" sign/symbol? How about Feynman Diagrams? Any thing at all to share? :-) _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bpaddock at csonline.net Mon Mar 4 17:29:07 2002 From: bpaddock at csonline.net (Bob Paddock) Date: Mon, 04 Mar 2002 20:29:07 -0500 Subject: [Xcircuit-dev] Editing Data Sheets? Message-ID: <200203042029968.SM00549@there> I have a .PDF data sheet that I'd like to extract sections from and include them in to a XCircuit schematic, preferably with out retyping/redrawing it by hand. I've tried using GhostScript to convert a page of the .PDF to .PS format. The .PS looks really bad, at any resolution, compared to the .PDF file. Any way is there a way to feed this in to XCircuit? I've tried Read, nothing use full happens. Import Background does do that, but you can't edit the background. Any ideas? _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Sat Mar 9 21:27:32 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Sun, 10 Mar 2002 00:27:32 -0500 Subject: [Xcircuit-dev] xcircuit for pdb layout Message-ID: <200203100527.AAA17996@stravinsky.jhuapl.edu> Dear Dave, > The website mentions that xcircuit can be used for PCB layout. How do I > switch from schematic to pcb? Perhaps that's a bit misleading. As some people like to PCBs for home-made circuits, sometimes all they want is a PostScript printout on the laser printer which can be etched into a copper-plated board. Xcircuit's PostScript output makes it useful for that. For anything more complicated than that, use the open-source tool "pcb", not xcircuit, for the layout. I hope that clarifies the statement in the website. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From dlandfried at adelphia.net Fri Mar 8 05:06:45 2002 From: dlandfried at adelphia.net (Dave Landfried) Date: Fri, 08 Mar 2002 08:06:45 -0500 Subject: [Xcircuit-dev] xcircuit pcb Message-ID: <57D56872-3295-11D6-A92C-0003933F5C6A@adelphia.net> The website mentions that xcircuit can be used for PCB layout. How do I switch from schematic to pcb? _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From robert_batey at agilent.com Wed Mar 13 07:46:00 2002 From: robert_batey at agilent.com (Bob Batey) Date: Wed, 13 Mar 2002 08:46:00 -0700 Subject: [Xcircuit-dev] editing of parameters Message-ID: <3C8F7438.B7BEDC08@agilent.com> Hi, I can't seem to delete characters in a parameter string using the 'e' option. It adds, but no delete. Is this a problem with key bindings or do I have to delete the whole thing and re-enter a new string? If you know how would you send me some hints as to how to get this to work. I tried looking at the tutorials, and they just show me how to add text. I'm using the 2.5.2 version of Xcircuit on a LINUX system. (Slackware LINUX, and I compiled the source.) If parameters are not easy to change, SPICE netlists will have the wrong values in them. As an example, I tried to change the 1.0 K ohm resistor to 1.0 ohms. I couldn't delete the "k". Robert Batey Agilent/Boise -------------- next part -------------- A non-text attachment was scrubbed... Name: robert_batey.vcf Type: text/x-vcard Size: 341 bytes Desc: Card for Bob Batey Url : http://www.opencircuitdesign.com/pipermail/xcircuit-dev/attachments/20020313/ee58ac5c/attachment.vcf From jhbrown at ai.mit.edu Fri Mar 15 11:52:07 2002 From: jhbrown at ai.mit.edu (Jeremy H. Brown) Date: Fri, 15 Mar 2002 14:52:07 -0500 Subject: [Xcircuit-dev] xcircuit 2.5.3: 2 bugs, 1 suggestion Message-ID: First, let me start by saying that xcircuit rocks -- thank you very, very much!!! These are just some minor things, mostly. Platform: debian linux, 2.2.19pre21 kernel Bug: Sometimes, if you create a pin, and then copy it, and then write a netlist, the copy and everything you've done afterward just disappear. On the other hand, if you create a pin, copy it, save the file, and restart xcircuit, and then generate a netlist from the file, everything works fine. Unfortunately, I have not been able to figure out how to reliably reproduce the bug yet. Minor bug: 'G' is documented as creating a global pin, but when pressed, xcircuit claims it isn't bound to macro. Suggestion: it's not obvious that one should use the mouse to click/drag the help screen in the help browser. Perhaps a sentence at the very start of the help content? Jeremy _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From jhbrown at ai.mit.edu Sat Mar 23 01:24:10 2002 From: jhbrown at ai.mit.edu (Jeremy H. Brown) Date: Sat, 23 Mar 2002 04:24:10 -0500 Subject: [Xcircuit-dev] xcircuit 2.5.3 bug report Message-ID: I figured out a means of reproducing the bug I reported in xcircuit a week or two back. 1) start xcircuit. 2) 'l' for library. 3) drag a nand to the center of page 1. 4) create three input wires connecting to the inputs of the NAND gate. length doesn't appear to matter. 5) 'T' to add a pin, name it "A", to the left end of the topmost wire 6) 'T' to add a pin "B" to the middle wire 7) select "netlist"->"write spice" 8) middle-button over "B" to select it; reject any wires that might also get selected, only select "B". 9) 'c' to copy pin B; place the copy in the middle of the bottommost wire with the middle button 10) select "netlist"->"write spice" --- and the copied "B" vanishes! This is the first manifestation of the bug. for more fun: 11) Copy the nand gate all over the place. Make some new wires. 12) select "netlist"->"write spice" -- all of the new wires and nand gates vanish! Jeremy _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Mon Mar 25 09:15:35 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Mon, 25 Mar 2002 12:15:35 -0500 Subject: [Xcircuit-dev] xcircuit disappearing labels Message-ID: <200203251715.MAA02035@stravinsky.jhuapl.edu> Dear Jeremy, Thanks for the detailed---and repeatable---bug report. I discovered the problem at netlist.c, line 3106, where the comment /* (All elements after the 1st temp label are temp labels) */ was rendered false by the method of retaining netlists. If you make a netlist, temporary labels which are not visible on the schematic get created. If you subsequently add more parts, they get wiped out the next time the netlist is invalidated. To correct the problem, the section following the comment needs to be a little more sophisticated. Change (netlist.c, line 3105 in source version 2.5.4): /* Free any temporary labels which have been created */ /* (All elements after the 1st temp label are temp labels) */ else if ((*cgen)->type == LABEL) { labelptr clab = TOLABEL(cgen); int tmpval = (int)(cgen - cschem->plist); if (clab->string->type != FONT_NAME) { while (cgen < cschem->plist + cschem->parts) { clab = TOLABEL(cgen); freelabel(clab->string); free(clab); cgen++; } cschem->parts = tmpval; break; } } to: /* Free any temporary labels which have been created */ else if ((*cgen)->type == LABEL) { labelptr clab = TOLABEL(cgen); int tmpval = (int)(cgen - cschem->plist); if (clab->string->type != FONT_NAME) { genericptr *tgen; clab = TOLABEL(cgen); freelabel(clab->string); free(clab); for (tgen = cgen + 1; tgen < cschem->plist + cschem->parts; tgen++) *(tgen - 1) = *tgen; cschem->parts--; cgen--; } } I have tested this and it gets rid of the problem. I have changed it in the distribution, which is now version 2.5.4 rev. 1. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From bryce at tlw.com Wed Apr 24 09:00:38 2002 From: bryce at tlw.com (Bryce Denney) Date: Wed, 24 Apr 2002 12:00:38 -0400 (EDT) Subject: [Xcircuit-dev] Multiple-gate chips in PCB netlists In-Reply-To: <200203251715.MAA02035@stravinsky.jhuapl.edu> Message-ID: I was hoping to draw a schematic with a quad op-amp, based on the quad NAND example in the quadparts library. However I cannot get the quad NAND to produce a usable pcb netlist. I have filed a few bugs on Source Forge describing the problems I'm seeing. Basically: 1. I can't find any way to specify power and ground connections in a multigate chip. Maybe one of the instances should have power and ground ports, and the others should not? 2. The pcb netlist output looks like U1-3-10, meaning part number U1, gate number 3, pin 10. This cannot be parsed in the pcb software, unless I change it to just U1-10. I know how to do this with a perl script to fix up the netlist, but is there a better way? I'm using xcircuit 2.5.2. Later versions are crashing on startup with an XQueryColors error. I filed that one too. :) Thanks, Bryce _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Wed Apr 24 09:38:51 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Wed, 24 Apr 2002 12:38:51 -0400 Subject: [Xcircuit-dev] xcircuit Q&A Message-ID: <200204241638.MAA02938@stravinsky.jhuapl.edu> Dear Bryce, > 1. I can't find any way to specify power and ground connections in a > multigate chip. Maybe one of the instances should have power and ground > ports, and the others should not? Put numbered pins for Vdd and GND on the library symbol (such as on top and bottom). On any one of the parts in the schematic, attach Vdd and GND (or attach labels with the global names Vdd and GND) to any one of the devices. You will, however, need to post-process the result to get rid of the redundant entries for those pins, as xcircuit only recognizes the problem well enough to report "duplicate entries U1 and U1" or something to that effect. I will work on this problem. > 2. The pcb netlist output looks like U1-3-10, meaning part number U1, gate > number 3, pin 10. This cannot be parsed in the pcb software, unless I > change it to just U1-10. I know how to do this with a perl script to fix > up the netlist, but is there a better way? The "info label" for the device has "pcb:U?-1" (or -2, -3, etc.). Edit it as follows: Select the last number in the string (with a middle-mouse- button select box) and then select menu option "Text->Unparameterize". Then edit the string and delete the "-1" off the end. You will no longer get the sub-component number in the PCB output. > I'm using xcircuit 2.5.2. Later versions are crashing on startup with an > XQueryColors error. I filed that one too. :) Yuck. I may need to see the actual error result, but try this: xcircuit.c, routine "findnearcolor" (around line 1807), add as the first executable code after the type declarations: if (ncolors > 256) { XQueryColor(dpy, cmap, cvexact); return cvexact->pixel; } The rest of the stuff in that routine was supposed to be dealing with indexed color; it is not relevant to 24- or 32- bit TrueColor visuals, and I suspect that's the problem. But it could be something else. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ackley at cs.unm.edu Wed Apr 24 11:36:34 2002 From: ackley at cs.unm.edu (David Ackley) Date: Wed, 24 Apr 2002 12:36:34 -0600 Subject: [Xcircuit-dev] Any hope for bug 544657? References: Message-ID: I'm getting bitten bad by the `button-down video signal loss', just as described in http://sourceforge.net/tracker/index.php?func=detail&aid=544657&group_id=4952&atid=104952 Is there any hope for progress on this one over the near term --- say maybe a month or so? Does anybody who's up the developer curve have the hardware to duplicate the problem? I'm going to have to commit to something fairly soon for drawing several chapters worth of schematics and figures... and I sure would like to benefit from xcircuit's libraries and beautiful output if I could. Thanks for any information. -Dave _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Wed Apr 24 12:07:40 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Wed, 24 Apr 2002 15:07:40 -0400 Subject: [Xcircuit-dev] Video blanking Message-ID: <200204241907.PAA04033@stravinsky.jhuapl.edu> Dear Dave, Obviously I'm not looking often enough through the xcircuit mailing list. Anyway, this is an essentially unsolvable problem: The X server is at fault, and confuses the timer between the screensaver and xcircuit, in spite of the fact that xcircuit provides its unique application ID when it registers the timeout event (well, the problem is either in the X server or in the screensaver). An unsatisfactory solution, but one which works, is to turn off your screensaver. If necessary, you could start xcircuit from a script which would revive the screensaver after you exit. As I said, it's not very satisfactory. I think I will try to abandon the X timeout function altogether and use a low-level interrupt timer instead. That might get rid of the problem. I'll give that a try, but I'll need somebody who experiences the problem to test it, since I can't duplicate this particular bug. Regards, Tim _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ken at 246gt.com Mon Apr 29 09:22:59 2002 From: ken at 246gt.com (ken restivo) Date: Mon, 29 Apr 2002 09:22:59 -0700 Subject: [Xcircuit-dev] Delete/Backspace and PCB output Message-ID: <20020429162259.GA30460@fred.246gt.com> An embedded and charset-unspecified text was scrubbed... Name: msg.pgp Url: http://www.opencircuitdesign.com/pipermail/xcircuit-dev/attachments/20020429/a777f890/attachment.pot From ericc at alumni.caltech.edu Fri May 10 09:24:20 2002 From: ericc at alumni.caltech.edu (Eric Y. Chang) Date: Fri, 10 May 2002 09:24:20 -0700 (PDT) Subject: [Xcircuit-dev] XCircuit debugging Message-ID: <200205101624.g4AGOK75022735@alumni.caltech.edu> Hi. I am trying to debug a broken connectivity problem in XCircuit. This problem relates to generating pcb netlists. After running through the tutorial on the bridge rectifier, a correct netlist is output with respect to nodes, but there is no connectivity. In other words, the diode bridge is floating with respect to the input. Anyway, I figured that I needed to first upgrade to the latest (unstable) version, 2.5.4. Unfortunately, this does not come up with usable menus. The menus are all green, with no text in them. I replaced the .Xdefaults with the new .ad file, and neither one worked. All green. Since green was the problem, I decided to remove all references to green in the .Xdefaults file for xcircuit. The odd thing is that this had very little effect. When I changed one of the lines, the menu fill changed to gray (even if I changed the entry to blue). When I removed all lines, except for the *foreground and *background lines, the problem still occured, indicating that the "green" issue was hardcoded in the program. I then removed all instances of green (Green3) etc from all c and header files, and the problem persisted. Also, I compared the source code in these sections with the working version 2.3.3. There appeared to be no major changes. That means that the green is coming from someplace else. There are no hardcoded references anymore to green in the code, header files or .Xdefaults, but the menus are still coming up green filled. The instances of green in the stable build are in the same places, and the stable build works. So, it is very likely that the green is coming from an entirely unrelated portion of the program generating a side effect. There is a very suspicious section in which a custom color table is loaded, but this is the same as in the stable build, which works. This code is apparently triggered when it is found that the current colors do not match within some kind of measure which is 512 in the code. Changing this number to 1024 has no effect, and neither does commenting out the custom color table routine. Obviously, what is going on is that the green is loaded into the color table by this custom generation routine, and there is some essentially unrelated change that is either corrupting the color table or assigning two important indices to either close or identical values of green. It may be difficult to duplicate this problem elsewhere since the X server on my system is limited to 256 colors. Since there is a working build, it may be possible to work on back by means of binary subdivision, but this will require a lot of patching back. Is there a better way to fix the problem by going right to it? Does any of this ring a bell? Thanks, Eric _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Fri May 10 10:06:19 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Fri, 10 May 2002 13:06:19 -0400 Subject: [Xcircuit-dev] XCircuit and strange colormaps Message-ID: <200205101706.NAA13267@stravinsky.jhuapl.edu> Dear Eric, This seems to have been precipitated by a change that was supposed to *fix* things in 8-bit mode, not break them. Compare routine CvtStringToPixel between version 2.5.4 and earlier versions; you might get better results by changing it back to the original. You also might have encountered "bug #5" (see the Manifest file, down toward the bottom), in which if your 8-bit colormap is close to being out of spare colors, and the allocation runs out in the middle of xcircuit's allocating all its colors, then the colormap may never be installed and colors will certainly be screwed up. I could never produce this problem on my machine, so I have always considered it too rare to be a worry. But now, you make me wonder. And, it could be a conflict between two systems implementing the same X routine differently; the problem I was trying to correct with the change to CvtStringToPixel in version 2.5.4 seemed awfully suspicious, in that XLookupColor was returning "success" but had a trash value in cvexact.pixel. If that's the case, reverting CvtStringToPixel to the original form might work for you. Finally, there's one more thing I thought of: it may be that xcircuit.c, line 2268 XtAppAddConverter(app, XtRString, XtRPixel, (XtConverter)CvtStringToPixel, NULL, 0); should really be at line 2242; that is, it should be called before XtOpenApplication() so that the same routine is applied to the fallback resources as is applied to the application resources. I suggest trying this solution first (before making any changes to CvtStringToPixel). At any rate, let me know what happens. Regards, Tim _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ericc at alumni.caltech.edu Sat May 11 16:45:51 2002 From: ericc at alumni.caltech.edu (Eric Y. Chang) Date: Sat, 11 May 2002 16:45:51 -0700 (PDT) Subject: [Xcircuit-dev] investigate Cvt Message-ID: <200205112345.g4BNjpZl011478@alumni.caltech.edu> Hi Tim. I tried a couple of things, both of which were successful. The first was to close Netscape. The menus looked fine then. So, this is caused by running out of colors, since Netscape takes up so many. Actually, it must take up some pretty crucial ones, since the page it was open to is the tutorial, with all the screenshots! So, one workaround is to close Netscape every time XCircuit is running, but this is a hassle, since I have to open it every now and then as I read the tutorial. The second thing that worked is to just revert the Cvt routine. That works just fine, and the old colors come back. This works even if Netscape is showing the tutorial. The reason why it works is that there is one major difference in the 2.5.4 code. If a non-zero code is returned from the color lookup, the 2.3.3 code will call findanothercolor (or something like that). This will build a private color table, and every subsequent call to Cvt will succeed rather than leaving the pixel member un-initialized. Obviously, the line was taken out for a reason, but I cannot figure out why. If there is a non-zero return code, .pixel should still be set, or else who knows what its value will be. This might even give a memory error. I will also try moving XtAppAddConverter up, but I don't see how this will help, especially since I am not sure how this routine works. I am not very fluent in Xt. Eric _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From NinjaME007 at aol.com Sun May 12 05:51:21 2002 From: NinjaME007 at aol.com (NinjaME007 at aol.com) Date: Sun, 12 May 2002 08:51:21 -0400 (EDT) Subject: [Xcircuit-dev] simulator Message-ID: Hey do you guys have a simulator that interfaces with xcircuit.......Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencircuitdesign.com/pipermail/xcircuit-dev/attachments/20020512/4b0bb867/attachment.html From tim at stravinsky.jhuapl.edu Mon May 13 07:15:23 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Mon, 13 May 2002 10:15:23 -0400 Subject: [Xcircuit-dev] Re: xcircuit colormap errors Message-ID: <200205131415.KAA01139@stravinsky.jhuapl.edu> Dear Eric, > The second thing that worked is to just revert the Cvt routine. Now I'll have to find a way to resolve the differences between the old and the new versions of Cvt... > Obviously, the line was taken out for a reason, but I cannot figure out > why. If there is a non-zero return code, .pixel should still be set, or > else who knows what its value will be. There is at least one system out there where LookupColor returns a completely bogus value in .pixel. It looks to me like a server error. Now I'm stuck with the problem that getting around the sever error breaks the code on systems with properly-working X servers. I may be reduced to adding it as an ugly compile-time switch. Thanks for checking out the bug fix suggestions and reporting back. Regards, Tim _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Mon May 13 07:21:38 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Mon, 13 May 2002 10:21:38 -0400 Subject: [Xcircuit-dev] Re: xcircuit simulator Message-ID: <200205131421.KAA01150@stravinsky.jhuapl.edu> > Date: Sun, 12 May 2002 08:51:21 -0400 (EDT) > From: NinjaME007 at aol.com > Subject: [Xcircuit-dev] simulator > Sender: xcircuit-dev-admin at lists.sourceforge.net > To: xcircuit-dev at lists.sourceforge.net > > Hey do you guys have a simulator that interfaces with xcircuit.......Thanks XCircuit does not [yet; I'm working on it] interface directly to a simulator. However, the SPICE output it produces is more-or-less compatible with all SPICE versions (you may need to hand-edit for specific versions; I'm working on that problem, too). The ".sim" output it produces is compatible with "irsim" (Berkeley VLSI tools). Interactive simulation *is coming*, although my original target date of June now seems overly optimistic. Regards, Tim _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ericc at alumni.caltech.edu Tue May 14 20:30:52 2002 From: ericc at alumni.caltech.edu (Eric Y. Chang) Date: Tue, 14 May 2002 20:30:52 -0700 (PDT) Subject: [Xcircuit-dev] RE: XCircuit netlist to pcb problems Message-ID: <200205150330.g4F3UqQG014809@alumnus.caltech.edu> Hi Tim. I used defaults for both runs. I did remember 1/6 in. The 2.3.3 did not work, but the 2.5.4 did. It came up with the correct netlist (having connectivity). Note that the 2.5.4 did not produce a picture in which the diode end points lined up with each other (now clear from your explanation). But, the netlist extraction worked just fine, presumably due to the tolerance for accepting a connection. The 2.3.3 drew a picture that was less well aligned. This could have been the root cause, or it could have been a netlisting bug. Anyway, I am now using 2.5.4 (which has incidentally had less crashing problems than 2.3.3 as well). It works just great for the netlisting, aside from the asthetically displeasing diode picture. Should enforce a 45 degree prohibition :-). Just kidding. Thanks for all the help. Eric >Dear Eric, > >> There is a hint of trouble since the items from the 2nd library >> seem to be on a different grid than the main drawing area. > >That would be a problem because they're not supposed to be different. >Do you have a ".xcircuitrc" file or have done something to the >default startup that would have redefined the grid and snap spacing? >You should get Grid=1/6in, Snap=1/12in on startup. The diode from >the 2nd library should be exactly three grid-spacings long. Turned >to 45 degrees, it fits diagonally inside a 2x2 grid-spacing box, >with the actually difference being within xcircuit's tolerance for >wire endpoint offsets. > >There was, however, a broken version of the PCB netlister posted >for a while which was only fixed in version 2.5.4, one of the first >revisions. > >If you're definitely seeing something different than what I'm >describing, then let me know. > > Regards, > Tim > _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ericc at alumni.caltech.edu Tue May 14 20:35:46 2002 From: ericc at alumni.caltech.edu (Eric Y. Chang) Date: Tue, 14 May 2002 20:35:46 -0700 (PDT) Subject: [Xcircuit-dev] Re: xcircuit colormap err Message-ID: <200205150335.g4F3ZkAc015018@alumnus.caltech.edu> Hi Tim. Do you need any help or investigation on this matter? Of course, my system does not have the LookupColor bug, but I can easily retrigger the limited color table size problem. How does removing the line help the case in which the pixel value that comes back from LookupColor is bogus? I first thought that the color table generation routine had problems, but it is in fact what saved the day when the colors were limited. Eric >Dear Eric, > >> The second thing that worked is to just revert the Cvt routine. > >Now I'll have to find a way to resolve the differences between the >old and the new versions of Cvt... > >> Obviously, the line was taken out for a reason, but I cannot figure out >> why. If there is a non-zero return code, .pixel should still be set, or >> else who knows what its value will be. > >There is at least one system out there where LookupColor returns a >completely bogus value in .pixel. It looks to me like a server error. >Now I'm stuck with the problem that getting around the sever error >breaks the code on systems with properly-working X servers. I may >be reduced to adding it as an ugly compile-time switch. > >Thanks for checking out the bug fix suggestions and reporting back. > > Regards, > Tim _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: bandwidth at sourceforge.net _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ericc at alumni.caltech.edu Fri May 17 20:35:16 2002 From: ericc at alumni.caltech.edu (Eric Y. Chang) Date: Fri, 17 May 2002 20:35:16 -0700 (PDT) Subject: [Xcircuit-dev] netlist to pcb layout flow Message-ID: <200205180335.g4I3ZGC5003605@alumnus.caltech.edu> Hi. I saw an e-mail in the archive dated around 10/2001 discussing the netlist to pcb layout flow. It discussed pin numbering/naming, and some hacks that are required. I am trying to work through the tutorial for xcircuit with the bridge rectifier. Recall that the bridge rectifier exercise defines a new user library element for the four diode structure. In the netlist, it looks like the top level instance name followed by a slash, then the diode name, then a dash and a pin number. For pcb, it would be most appropriate to construct an element which represents a bridge rectifier that one could buy at an electronics store (i.e. a square with 4 leads and a hole in the middle, maybe). If one does this, however, it would seem that its single instance should have a unique name (assigned in pcb) rather than the multitude of names in the input netlist (from xcircuit). Of course, one could always hand edit the .pcb input netlist, but is there a more elegant way to do this? Or is there something that I'm not seeing? I was wondering if there is a tutorial or "HOW-TO" for xcircuit-pcb integration. I searched google and did not find much of anything, but there was that suggestive and helpful e-mail in the archive. Anything else? Thanks, Eric _______________________________________________________________ Hundreds of nodes, one monster rendering program. Now that's a super model! Visit http://clustering.foundries.sf.net/ _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Wed May 22 07:28:16 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Wed, 22 May 2002 10:28:16 -0400 Subject: [Xcircuit-dev] xcircuit, PCB, and hierarchy Message-ID: <200205221428.KAA15389@stravinsky.jhuapl.edu> Dear Eric, > I do agree that hierarchical > PCB layout processes are important, from the standpoint of simplicity. > But, on the other hand, hierarchical layout is often avoided unless it > is imposed by machine constraints. XCircuit has no problem flattening designs; it's really an issue of naming conventions. What xcircuit ends up with (and "magic", and other hierarchically-based layout tools) is a flat representation with hierarchical names such as rectifier1/diode3.1 and so forth. To give that diode a unique name from the top level, so that the diode is just "D7", say, is a great idea, but xcircuit can't handle passing parameters through several levels of hierarchy. I come back to this issue every now and then, as it is an extraordinarily useful concept that is extraordinarily difficult to implement. On top of that, the tutorials, and probably the xcircuit interface overall, have a clear VLSI bias, because that's what I do. Occasionally I build PCBs but I have yet to get into the habit of doing LVS on them. Usually, that's not especially useful, as most of my errors stem from misreading datasheets, where LVS won't do any good anyway. It's only when you get into 4+ layers on a PCB, or when you get into big production runs, that you get into situations where it becomes prohibitively expensive to fix errors on the board. > I redid the tutorial without the hierarchical > grouping, and it worked just fine. The reason I haven't worked too much on the hierarchy-to-PCB concept is that it works just fine if you start with a flat design in xcircuit. I should probably separate out the VLSI and PCB parts of the tutorial so that I can properly stress the use of hierarchy for VLSI but de-stress it for PCB layout. > Probably, pcb's are not all that hierarchical because if they were, > it might be less expensive to do the arrays in VLSI, gals or FPGA's. > If digital logic is used, it might just be easier to use one of > Lattices new ISP's. They even have a downloadable tool chain. Funny you should mention that. My "counterexample", the 34-channel biosonar frontend board, has more Lattice ISP chips on it than probably any other board ever built (104, to be exact. . . these are the ispPAC programmable analog chips, which is why there are so many of them). I made a subcell of 3 ispPAC chips, capacitors, and wiring, and copied it 34 times. In PCB, I had to be absolutely sure that subcell was correct before copying it, because further changes would have to be done to each part individually instead of once, to the subcell. Lattice's downloadable tool chain has been an annoyance from the start. For the analog chips, I wrote my own software so I could program all 102 chips at once, feeding them high-level parameters such as filter frequency and Q. I used one of their digital chips, the 6192FF, as an interface chip, but I can only compile the schematic on their Windows- only tool. I do the schematics in Windows, too. It nearly drove me to write an EDIF output style for xcircuit, but I just didn't have the time. Generally speaking, though, most people use FPGAs to implement great gobs of logic like state machines and glue logic, which isn't hierarchical at all. The benefit of the FPGA is that 1) you can fix it if it's wrong, and 2) you know all the timing delays for simulation without having to lay out the board. > Somehow, it seems that there should be a way to insure that the > parts correspond between the two tools. My feeling is that the problem lies in the LVS tools. It should not be necessary to ensure a perfect correspondence between part numbers; if two parts are 74HCT244s, then it should not make a difference that the one on the PCB is labeled #1 and the one on the schematic is labeled #2. Or for that matter, that the one on the schematic has a hierarchical name and the one on the PCB has a flat name. From this standpoint, I'd like to get into "pcb" sometime and fix the way it handles netlists. I've also been thinking about writing an inherently hierarchical LVS tool. For highly arrayed designs, it would be orders of magnitude faster, take less memory, and produce more meaningful results. Just another thing I'll get around to if I have the time. Regards, Tim _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From ericc at alumni.caltech.edu Tue May 28 17:10:58 2002 From: ericc at alumni.caltech.edu (Eric Y. Chang) Date: Tue, 28 May 2002 17:10:58 -0700 (PDT) Subject: [Xcircuit-dev] converting generic lib to pcb aware Message-ID: <200205290010.g4T0Aw2b001321@alumnus.caltech.edu> Hi. I am almost done with setting up the XCircuit to pcb flow. The flow on standard parts works (but there still are some bugs, for example, rat lines in pcb will not refresh unless the program is restarted). Custom parts are now working, using some suggestions from the netlisting tutorials, but it is still a bit inconvenient managing the libraries. The remaining problem lies in generic parts that one is attempting to elevate to annotated status by adding info pins. It does not work. Adding a single info pin as recommended in Task 14 of the tutorial does not work, and adding multiple info pins as found by editing parts in analoglib2.lps does not work. The problem is that the "?" is propagated into the pcb netlist, where pcb is unable to resolve it. This occurs, for example, when one takes the crystal symbol ( -|[]|- , sort of), places an instance of it, and either edits the instance, or runs "m" on the instance to generate an object in the user library. If diagnostic printout is performed in writepcb() (in netlist.c), within parseinfo(), the place where the info pin is read may be checked. If the crystal is call X or xt, the token with a ? appears in the Page*.pcb file, without the ? being replaced by an incremented device index. This replacement works for R and C. It was found that entries in the postscript XCircuit file (schematic) contained the spurious "?" only for the new object, not for R and C, so the question mark was supposed to have been trimmed out before this time. That means that writepcb(), which is excuted much later does not have the bug. The bug is upstream. The code is difficult to navigate. Any ideas where the bug could be? Note that since the custom flow works, it should be possible to build the crystal object from scratch as was done above with ASCII art. Then, the suggestions from task 14 may be applied to add info pins so that pcb can use the netlisted output. This does work, but it is preferable to be able to transfer the symbols without having to redraw all of them. Any suggestions? Thanks, Eric _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev From tim at stravinsky.jhuapl.edu Wed May 29 08:54:27 2002 From: tim at stravinsky.jhuapl.edu (R. Timothy Edwards) Date: Wed, 29 May 2002 11:54:27 -0400 Subject: [Xcircuit-dev] xcircuit to pcb flow Message-ID: <200205291554.LAA29955@stravinsky.jhuapl.edu> Dear Eric, I think the problem is that you missed the instructions down at the bottom of tutorial step 14: "After creating the label, use the second mouse button to drag a select box over the question mark. Only the question mark should be highlighted. Then select menu item Text->Parameterize. As described earlier in the tutorial, the PCB netlister will use this parameterized string to determine a part number for the diode, or else the part number can be explicitly declared by editing the info label from each of the four instances of symbol "diode" that we will generate." A question mark is just a question mark. A *parameterized* question mark is a part number. It has to be a parameter of the symbol, or xcircuit can't supply a unique value for each instance of the object. So, the info label for the crystal should look like "pcb:X?" but when editing, the spelled-out version of the label in the message box should look like: "Font=Helvetica p c b : X Parameter(1)< ? >" I did this, stuck it into a simple circuit, and (with pin names changed from x.1, x.2 to simple numbers 1 and 2) I get a PCB output with "X1-1" and "X1-2". The difference shows up in the output file with the original having the definition for object "crystal" like this: /crystal { begingate . . . and the new one having this: /crystal { (?) 1 beginparm . . . Hopefully this clears up the problems. Regards, Tim _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcircuit-dev > > Woops! Lost half a year's email here. . . >