From tim at opencircuitdesign.com Fri Jan 4 06:29:44 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] Re: Magic VLSI installation on OS-X In-Reply-To: References: <477AEFA2.40804@opencircuitdesign.com> <477C5766.9060908@opencircuitdesign.com> Message-ID: <477E42D8.5030705@opencircuitdesign.com> Dear Nick, > When I tried the command "./configure" under Magic directory, it showed > the following at the end > ----------------------------------------------------------- > BLT: no ----------------------------------------------- > I'm not too sure what BLT is. BLT is a package for Tcl that you can probably find somewhere for the Mac. However, in Magic it is used only for the window that gives a tree view listing of cells, and Magic will work perfectly well without it. > So far, I have not fixed the permission problem as the command you > provided didn't work for me. > How do you look for the top directory tree? > I think my top directories are "Desktop, Library, Documents, > Music...etc" when I type cd, but apparently they are not the top directory. From your install log, it looks like the compile & install worked just fine. I think the only problem here is that you are used to the Mac environment, whereas this distribution is dependent on the fact that OS-X is really just an implementation of UNIX, and very little has been done to the code to make it more integrated with the Mac environment other than the minimum amount necessary to get it to compile cleanly. I'm not sure what passes for a terminal or console window on the Mac, but if you can get a command-line prompt, then you should be able to launch Magic by typing "/usr/local/bin/magic". It sounds like you want a desktop icon to launch Magic, but setting that up is beyond my limited range of knowledge about OS-X. If you still have problems, then I strongly suggest that you post a question to magic-dev@csl.cornell.edu, because there really are people who read the email postings regularly, and who have solved these problems before. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From graham.petley at vlsitechnology.org Sun Jan 13 08:12:08 2008 From: graham.petley at vlsitechnology.org (Graham Petley) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] Updated release of open source standard cell libraries Message-ID: <144629.80906.qm@web202.biz.mail.re2.yahoo.com> Hallo, Release 8.5 of my open source standard cell libraries can be downloaded from http://www.vlsitechnology.org This release has greatly improved the quality of the Magic views, tech files, colour maps and extraction accuracy. All Magic info has been put into one version 33 tech file instead of the multiple version 27 files. The kludge that was previously necessary for extraction (involving scripts to hack the extracted spice decks) has been removed. I think the extraction parameters are typical for a 0.13um technology. I'm documenting the methodology and will post the link here when done. As before, the cells are drawn in Alliance Graal; read into Magic; spice decks extracted and then characterised with winspice (which works in Linux with wine). Schematics are drawn with Xcircuit and there is an on-line data book. One note: You'll need version 7.5.95 or higher of Magic because the tech file uses some of the latest tech file features. Best regards, Graham Petley Screen shot of Magic http://www.vlsitechnology.org/gif/example_magic.gif From vidhya.ramesh at wipro.com Wed Jan 16 14:38:12 2008 From: vidhya.ramesh at wipro.com (vidhya.ramesh@wipro.com) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] regd installation Message-ID: Hi, I wanted to get magic(free version) to be installed in my laptop, I have only windows OS .is it possible to get installed. if yes mail me the procedure. Thanks in advance, Regards vidhya The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://vlsi.csl.cornell.edu/pipermail/magic-dev/attachments/20080116/e5d8f7fd/attachment.html From prnelson at csupomona.edu Tue Jan 22 20:57:47 2008 From: prnelson at csupomona.edu (Dr. Phyllis R. Nelson) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] RE: [Xcircuit-dev] Magic problem with MacOSX 10.5 References: <1201051104.25204@flurry.he.net> Message-ID: <12A3F9827C9A0244B13F90CDF45EBC4902DA9730@EX01.win.csupomona.edu> Tim and all, Thanks for looking into this problem! There may be some clues in the following discussion of the new launchd approach to starting X11 programs under Xquartz and os x 10.5: Biggest user-visible change in Leopard X11 is a new launch-on-demand support, courtesy of launchd. If you start a program that tries to open your X $DISPLAY, launchd will check to see if X11.app is running. If not, it will automatically start it for you. So on Leopard, just run a command like xterm or start an application that needs X11, and X11 will start up automatically. This means that now you can just run X apps like you would any other app. But this launch-on-demand functionality only works correctly if X11.app is launched on demand. So don't run X11.app from the Dock. Or, at all, manually. Ensure that you are not explicitly setting $DISPLAY in any configuration files as it will throw away the location of the launchd socket that X clients need to know how to use, verify that 'echo $DISPLAY' in Terminal.app reports something that starts with '/tmp/launchd', and then just run 'xterm &' from Terminal. This will work with any X11 client application that links with the standard libX11.dylib. This excerpt is from a longer discussion of X11 and leopard at http://homepage.mac.com/sao1/X11/index.html Thanks again! -Phyllis Phyllis Nelson, PhD Professor, Electrical and Computer Engineering co-Director, Center for Macromolecular Modeling and Materials Design California State Polytechnic University, Pomona email: prnelson at csupomona dot edu voice: (90(0 869-2649 (email preferred) office: building 9 room 131 lab: building 9 room 102 -----Original Message----- From: xcircuit-dev-bounces@opencircuitdesign.com on behalf of R. Timothy Edwards Sent: Tue 1/22/2008 5:18 PM To: Zappa Cc: xcircuit-dev@opencircuitdesign.com; magic-dev@csl.cornell.edu Subject: Re: [Xcircuit-dev] Magic problem with MacOSX 10.5 Dear Dario, > I am Dario, a student of Brescia (Italy). I'm using Magic in a > Microelectronics course, to design a PLL in a 0.18u technology. > I have some problem to run Magic on my old Mac iBook G4, with MacOSX > 10.5.1 (Leopard with Service Pack and X11) installed. > I install Xcode, the development kit by Apple to compile the source > code. I correctly set the "./configure" and I succesfully compile > with the argoument "-with-interpreter=tcl" (I have TCL/TK 8.4.7 > installed by default on my PC) for powerpc-apple-darwin9.1.0. > Everything is succesful (apart that it can't find OpenGL, so I use > X11 that is enough for me), but when I try to execute magic it give > me a "segmentation fault" in the "wish" application. In particular, > if I try to debug that error with: > > gdb /usr/local/lib/magic/tcl/magicexec > run > > it tells me: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x732e2050 > 0x0059a49c in XDefaultColormap () This is, I think, the third email I've gotten about this problem, two related to Magic and one to XCircuit. The problem seems not to be the Magic or XCircuit code itself, but the calls to X11 colormap functions. This problem seems to have started cropping up with OS-X 10.5 as people attempt to compile directly. Previously, I think everyone compiled using "fink", although with my lack of knowledge about Mac OS-X, I don't know any of the details. What I understand about this particular problem is that OS-X crashes immediately on calls such as XDefaultColormap(), XInstallColormap(), and XAllocNamedColor(). In the last function listed, used in XCircuit, the colormap is retrieved from Tk_Colormap(), which returns a low-integer value (like, say, 4). This is very unlike colormap values used by X11, which tend to be addresses in upper memory spaced converted to an integer. That is not necessarily wrong, but it's really the only thing I can find that is remotely unusual in the stack traces. I poked around with Google for any mention of such a problem but came up with nothing. So I am copying this message to the magic-dev and xcircuit-dev mailing lists, hoping that one of the OS-X people monitoring the lists knows something about the problem, even (hopefully) how to fix it. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim.edwards@multigig.com | | MultiGiG, Inc. | web: http://www.multigig.com | | 100 Enterprise Way Suite A-3 | phone: (831) 621-3283 | | Scotts Valley, CA 95066 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ _______________________________________________ Xcircuit-dev mailing list Xcircuit-dev@opencircuitdesign.com http://www.opencircuitdesign.com/mailman/listinfo/xcircuit-dev From timothy_edwards at multigig.com Tue Jan 22 17:18:24 2008 From: timothy_edwards at multigig.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] Re: Magic problem with MacOSX 10.5 Message-ID: <1201051104.25204@flurry.he.net> Dear Dario, > I am Dario, a student of Brescia (Italy). I'm using Magic in a > Microelectronics course, to design a PLL in a 0.18u technology. > I have some problem to run Magic on my old Mac iBook G4, with MacOSX > 10.5.1 (Leopard with Service Pack and X11) installed. > I install Xcode, the development kit by Apple to compile the source > code. I correctly set the "./configure" and I succesfully compile > with the argoument "-with-interpreter=tcl" (I have TCL/TK 8.4.7 > installed by default on my PC) for powerpc-apple-darwin9.1.0. > Everything is succesful (apart that it can't find OpenGL, so I use > X11 that is enough for me), but when I try to execute magic it give > me a "segmentation fault" in the "wish" application. In particular, > if I try to debug that error with: > > gdb /usr/local/lib/magic/tcl/magicexec > run > > it tells me: > > Program received signal EXC_BAD_ACCESS, Could not access memory. > Reason: KERN_INVALID_ADDRESS at address: 0x732e2050 > 0x0059a49c in XDefaultColormap () This is, I think, the third email I've gotten about this problem, two related to Magic and one to XCircuit. The problem seems not to be the Magic or XCircuit code itself, but the calls to X11 colormap functions. This problem seems to have started cropping up with OS-X 10.5 as people attempt to compile directly. Previously, I think everyone compiled using "fink", although with my lack of knowledge about Mac OS-X, I don't know any of the details. What I understand about this particular problem is that OS-X crashes immediately on calls such as XDefaultColormap(), XInstallColormap(), and XAllocNamedColor(). In the last function listed, used in XCircuit, the colormap is retrieved from Tk_Colormap(), which returns a low-integer value (like, say, 4). This is very unlike colormap values used by X11, which tend to be addresses in upper memory spaced converted to an integer. That is not necessarily wrong, but it's really the only thing I can find that is remotely unusual in the stack traces. I poked around with Google for any mention of such a problem but came up with nothing. So I am copying this message to the magic-dev and xcircuit-dev mailing lists, hoping that one of the OS-X people monitoring the lists knows something about the problem, even (hopefully) how to fix it. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim.edwards@multigig.com | | MultiGiG, Inc. | web: http://www.multigig.com | | 100 Enterprise Way Suite A-3 | phone: (831) 621-3283 | | Scotts Valley, CA 95066 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From fang at csl.cornell.edu Thu Jan 24 12:54:56 2008 From: fang at csl.cornell.edu (David Fang) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] Re: Magic problem with MacOSX 10.5 In-Reply-To: <1201051104.25204@flurry.he.net> References: <1201051104.25204@flurry.he.net> Message-ID: <20080124124356.M60256@shannon.csl.cornell.edu> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_INVALID_ADDRESS at address: 0x732e2050 >> 0x0059a49c in XDefaultColormap () > > This is, I think, the third email I've gotten about this problem, two > related to Magic and one to XCircuit. The problem seems not to be > the Magic or XCircuit code itself, but the calls to X11 colormap > functions. This problem seems to have started cropping up with > OS-X 10.5 as people attempt to compile directly. Previously, I > think everyone compiled using "fink", although with my lack of > knowledge about Mac OS-X, I don't know any of the details. Hi, I last packaged up magic 7.1 and 7.4 for fink about a year ago, but only tested 7.1 more against various Mac architectures and OS releases, while 7.4 only got minimal packaging testing. (I don't know how many out there have actually tested the 7.4 packaging in the unstable tree, so there may be issues, though I've receive no reports, positive or negative.) I don't have a 10.5 machine handy, so I might not get around to it until I get one (and have some time on my hands). I do know that X11's code base has shifted to Xorg's 7.2 from xfree86's R6.8, and has had a bit of a rough start. Perhaps check the archives or ask around on the "x11-users@lists.apple.com" mailing list for X11 issues. > What I understand about this particular problem is that OS-X > crashes immediately on calls such as XDefaultColormap(), > XInstallColormap(), and XAllocNamedColor(). In the last > function listed, used in XCircuit, the colormap is retrieved from > Tk_Colormap(), which returns a low-integer value (like, say, 4). > This is very unlike colormap values used by X11, which tend to > be addresses in upper memory spaced converted to an integer. > That is not necessarily wrong, but it's really the only thing I > can find that is remotely unusual in the stack traces. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) From philippe at alpha.ece.jhu.edu Sun Jan 27 13:14:09 2008 From: philippe at alpha.ece.jhu.edu (Philippe Pouliquen) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] regd installation In-Reply-To: References: Message-ID: <20080127131059.R51591@alpha.ece.jhu.edu> Hi Vidhya, > I wanted to get magic(free version) to be installed in my laptop, I have > only windows OS .is it possible to get installed. if yes mail me the > procedure. The simplest procedure is to install Cygwin (www.cygwin.com) on your Windows system. This will provide your computer with a UNIX-like environment suitable for compiling and installing Magic and other useful tools. Note that you will need to select X11 for installation manually, as it is not selected by default by the Cygwin installer. Philippe Pouliquen The Johns Hopkins University From mtdos at erols.com Sun Jan 27 19:53:58 2008 From: mtdos at erols.com (Michael Doster) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] Re: Magic problem with MacOSX 10.5 In-Reply-To: <1201051104.25204@flurry.he.net> References: <1201051104.25204@flurry.he.net> Message-ID: <84E1566B-334F-45CD-A267-A347CFAA20B2@erols.com> Just so this is documented in the mailing list, I've found the solution to why OpenGL isn't compiled in 10.5.0 (10.5.1 as well) even when asked for. LDFLAGS needs to be set to "-Wl,-dylib_file,/System/ Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/ System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib". See the following Apple forum entry for details: http://lists.apple.com/archives/x11-users/2007/Oct/msg00146.html This has been tested with the following on an Intel Mac: magic-7.4.57 Tcl 8.4.16 Tk 8.4.16 BLT 2.4 Also with this compiled setup the I did not see the gdb error. Michael Doster On Jan 22, 2008, at 8:18 PM, R. Timothy Edwards wrote: > Dear Dario, > >> I am Dario, a student of Brescia (Italy). I'm using Magic in a >> Microelectronics course, to design a PLL in a 0.18u technology. >> I have some problem to run Magic on my old Mac iBook G4, with MacOSX >> 10.5.1 (Leopard with Service Pack and X11) installed. >> I install Xcode, the development kit by Apple to compile the source >> code. I correctly set the "./configure" and I succesfully compile >> with the argoument "-with-interpreter=tcl" (I have TCL/TK 8.4.7 >> installed by default on my PC) for powerpc-apple-darwin9.1.0. >> Everything is succesful (apart that it can't find OpenGL, so I use >> X11 that is enough for me), but when I try to execute magic it give >> me a "segmentation fault" in the "wish" application. In particular, >> if I try to debug that error with: >> >> gdb /usr/local/lib/magic/tcl/magicexec >> run >> >> it tells me: >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_INVALID_ADDRESS at address: 0x732e2050 >> 0x0059a49c in XDefaultColormap () > > This is, I think, the third email I've gotten about this problem, two > related to Magic and one to XCircuit. The problem seems not to be > the Magic or XCircuit code itself, but the calls to X11 colormap > functions. This problem seems to have started cropping up with > OS-X 10.5 as people attempt to compile directly. Previously, I > think everyone compiled using "fink", although with my lack of > knowledge about Mac OS-X, I don't know any of the details. > > What I understand about this particular problem is that OS-X > crashes immediately on calls such as XDefaultColormap(), > XInstallColormap(), and XAllocNamedColor(). In the last > function listed, used in XCircuit, the colormap is retrieved from > Tk_Colormap(), which returns a low-integer value (like, say, 4). > This is very unlike colormap values used by X11, which tend to > be addresses in upper memory spaced converted to an integer. > That is not necessarily wrong, but it's really the only thing I > can find that is remotely unusual in the stack traces. > > I poked around with Google for any mention of such a problem but > came up with nothing. > > So I am copying this message to the magic-dev and xcircuit-dev > mailing lists, hoping that one of the OS-X people monitoring the > lists knows something about the problem, even (hopefully) how to > fix it. > > Regards, > Tim > > +-------------------------------- > +-------------------------------------+ > | Dr. R. Timothy Edwards (Tim) | email: > tim.edwards@multigig.com | > | MultiGiG, Inc. | web: http:// > www.multigig.com | > | 100 Enterprise Way Suite A-3 | phone: (831) > 621-3283 | > | Scotts Valley, CA 95066 | cell: (240) > 401-0616 | > +-------------------------------- > +-------------------------------------+ > > _______________________________________________ > magic-dev mailing list > magic-dev@vlsi.cornell.edu > http://vlsi.csl.cornell.edu/mailman/listinfo/magic-dev From bertrand at asicadvantage.com Fri Feb 1 12:25:12 2008 From: bertrand at asicadvantage.com (Bertrand Irissou) Date: Thu Oct 30 14:34:09 2008 Subject: [Magic-dev] Reading macros based on technology used Message-ID: <22991478.13451201897512779.JavaMail.root@zimbra.asicadvantage.com> Hi Everyone,, I use several different technologies for which many of the macros are differents. For instance, I have scmos1.tech for which I use scmos1.macros, scmos2.tech with scmos2.macros, etc... You get the idea :) I there a construct I can use in the site.def to have scmos1.macros automatically read in when I invoke "magic -T scmos1.tech", scmos2.macros when I invoke "magic -T scmos2.tech" without requiring local .magicrc ? Similarly, having a ".tcl" script read in on a per technology basis would be great. Sincerely, Bertrand. From tim at opencircuitdesign.com Sun Feb 3 11:30:58 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Re: Reading macros based on technology used In-Reply-To: <22991478.13451201897512779.JavaMail.root@zimbra.asicadvantage.com> References: <22991478.13451201897512779.JavaMail.root@zimbra.asicadvantage.com> Message-ID: <47A61672.9060800@opencircuitdesign.com> Dear Bertrand, > I use several different technologies for which many of the macros are differents. > For instance, I have scmos1.tech for which I use scmos1.macros, scmos2.tech with > scmos2.macros, etc... You get the idea :) > I there a construct I can use in the site.def to have scmos1.macros automatically > read in when I invoke "magic -T scmos1.tech", scmos2.macros when I invoke > "magic -T scmos2.tech" without requiring local .magicrc ? Similarly, having a ".tcl" > script read in on a per technology basis would be great. I tend to treat such script files as per-project, not per-technology, and I put them in the project's .magicrc file. This keeps the technology file itself more portable, although it does require vigilance on the part of the user or administrator to ensure that each new project is set up correctly. Putting something in the site.def file would account for whatever is on the command line after the "-T" argument, but would not account for technology files loaded from the .magicrc file with the "tech load" command. If one assumes that the .magicrc file will take care of its own reading of script files, then the site.def file can do it by, e.g., catch {source [file root [tech filename]].tcl} which will look for, and source (for example) file "scmos.tcl" after reading "scmos.tech" (and assumes that scmos.tcl is in the same directory as scmos.tech). ---Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From fedor at qwestoffice.net Wed Mar 5 12:36:45 2008 From: fedor at qwestoffice.net (Adam Fedor) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Re: Magic problem with MacOSX 10.5 Message-ID: <8E6F6D6F-D171-4B49-AD1D-C47282C8B7E8@qwestoffice.net> Just some more information on OSX 10.5 (Intel), magic is available for Mac OS X via macports (www.macports.org) - macports works by downloading the source and compiling the package (after downloading and installing any dependancies). With 10.5/Intel via macports, magic also has the same problem crashing on XDefaultColormap, UNLESS you compile and install Tk/Tcl via ports as well instead of using the one that comes with 10.5. So port install tk port install magic (as root) works - mostly - I still get an odd error: ========= Error in startup script: version conflict for package "Tk": have 8.5.1, need exactly 8.5 while executing "package require -exact Tk $tcl_version" invoked from within "if {$tcl_version < 8.0} { return -code error "tkcon requires at least Tcl/Tk8" } else { package require -exact Tk $tcl_version }" (file "/opt/local/lib/magic/tcl/tkcon.tcl" line 44) ====== But that's easy to work around (start with magic -noc) and at least seems easier to solve... From isabelle.bouchoule at institutoptique.fr Tue Mar 18 14:49:20 2008 From: isabelle.bouchoule at institutoptique.fr (isabelle bouchoule) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] installation problem Message-ID: <47DFBA50.30504@institutoptique.fr> Dear user of magic, I tried to installed magic-7.4.59 on my computer. When I type "make config", everything is fine. No make.log is generated. But when I type "make", then I have the error message $ sudo make --- errors and warnings logged in file make.log --- making modules --- compiling cmwind/CMWmain.o CMWmain.c:26:25: erreur: utils/magic.h : Aucun fichier ou r?pertoire de ce type CMWmain.c:27:28: erreur: utils/geometry.h : Aucun fichier ou r?pertoire de ce type CMWmain.c:28:29: erreur: windows/windows.h : Aucun fichier ou r?pertoire de ce type ..... My computer is runing under ubuntu 7.10 (gusty), Kernel linux 2.6.22-14. If it helps you, below is the output of make config : sudo make config [sudo] password for isabelle: ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for cpp... cpp checking for library containing strerror... none required checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for gm4... no checking for gnum4... no checking for m4... /usr/bin/m4 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for void *... yes checking size of void *... 4 checking for unsigned int... yes checking size of unsigned int... 4 checking for unsigned long... yes checking size of unsigned long... 4 checking for unsigned long long... yes checking size of unsigned long long... 8 checking whether byte ordering is bigendian... no checking for ANSI C header files... (cached) yes checking for setenv... yes checking for putenv... yes checking for vfork... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking param.h usability... no checking param.h presence... no checking for param.h... no checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking for va_copy... yes checking for __va_copy... yes checking for built-in roundf... yes checking for built-in round... yes checking for gcore... /usr/bin/gcore checking for csh... /bin/csh checking for X... libraries , headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for XOpenDevice in -lXi... no checking for tclConfig.sh... /usr/lib/tcl8.4/tclConfig.sh checking for tkConfig.sh... /usr/lib/tk8.4/tkConfig.sh checking for wish executable... /usr/bin/wish checking for tclsh executable... /usr/bin/tclsh checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for glXCreateContext in -lGL... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes configure: creating ./config.status config.status: creating defs.mak ----------------------------------------------------------- Configuration Summary (principle requirements): X11: yes OpenGL: yes Tcl/Tk: yes BLT: yes ----------------------------------------------------------- Use 'make' to compile and 'make install' to install. Errors may not be printed to stdout: see files 'make.log' and 'install.log' for complete error summary. ----------------------------------------------------------- Thank you for your help, Isabelle. -- Isabelle Bouchoule Charg?e de recherche Laboratoire Charles Fabry de l'Institut d'Optique Campus polytechnique, RD 128 91 127 Palaiseau Cedex tel : (33) 1 64 53 33 38 (33 59) From tim at opencircuitdesign.com Wed Mar 19 11:38:19 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] installation problem In-Reply-To: <47DFBA50.30504@institutoptique.fr> References: <47DFBA50.30504@institutoptique.fr> Message-ID: <47E14F8B.2090302@opencircuitdesign.com> Dear Isabelle, > I tried to installed magic-7.4.59 on my computer. When I type "make > config", everything is fine. No make.log is generated. But when I type > "make", then I have the error message > > $ sudo make > --- errors and warnings logged in file make.log > --- making modules > --- compiling cmwind/CMWmain.o > CMWmain.c:26:25: erreur: utils/magic.h : Aucun fichier ou r?pertoire de > ce type > CMWmain.c:27:28: erreur: utils/geometry.h : Aucun fichier ou r?pertoire > de ce type > CMWmain.c:28:29: erreur: windows/windows.h : Aucun fichier ou r?pertoire > de ce type > ..... I learned French before the Internet age, but I did manage to translate "no such file or folder". The path to header files declared in quotes (like #include "utils/magic.h") must be relative to some "-I " passed to the compiler. In magic, this is done in the file "defs.mak" in the definition "CPPFLAGS =". This normally says CPPFLAGS = -I. -I${MAGICDIR} Change "${MAGICDIR}" to the full path of the top-level source directory, and I think it should compile properly. Alternately, it may be that the problem is caused by using "sudo", and you may get better results by simply doing "make". Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From aanjhan at gmail.com Fri Apr 4 00:48:37 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 Message-ID: Hello, I am trying to compile the magic latest stable on Ubuntu Gutsy. Have installed the deps tcl/tk and btl things. configure passes. But I get the below error while doing a make. Can someone please help? Or am I missing something? Also I changed the makedbh file to have /bin/sh instead of /bin/csh. make[1]: Entering directory `/home/tuxmaniac/Desktop/magic-7.5.129' --- making header file database/database.h ./scripts/makedbh database/database.h.in database/database.h ./scripts/makedbh: 54: Syntax error: "(" unexpected (expecting "do") make[1]: *** [database/database.h] Error 2 make[1]: Leaving directory `/home/tuxmaniac/Desktop/magic-7.5.129' make[1]: Entering directory `/home/tuxmaniac/Desktop/magic-7.5.129' --- making header file database/database.h ./scripts/makedbh database/database.h.in database/database.h ./scripts/makedbh: 54: Syntax error: "(" unexpected (expecting "do") make[1]: *** [database/database.h] Error 2 make[1]: Leaving directory `/home/tuxmaniac/Desktop/magic-7.5.129' make[1]: Entering directory `/home/tuxmaniac/Desktop/magic-7.5.129' --- making header file database/database.h ./scripts/makedbh database/database.h.in database/database.h ./scripts/makedbh: 54: Syntax error: "(" unexpected (expecting "do") make[1]: *** [database/database.h] Error 2 make[1]: Leaving directory `/home/tuxmaniac/Desktop/magic-7.5.129' Thanks in Advance. Regards, -- Aanjhan From fang at csl.cornell.edu Fri Apr 4 15:10:37 2008 From: fang at csl.cornell.edu (David Fang) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: References: Message-ID: <20080404140753.K49056@shannon.csl.cornell.edu> > I am trying to compile the magic latest stable on Ubuntu Gutsy. Have > installed the deps tcl/tk and btl things. configure passes. But I get > the below error while doing a make. Can someone please help? Or am I > missing something? Also I changed the makedbh file to have /bin/sh > instead of /bin/csh. Hi, /bin/sh and /bin/csh are not equivalent; you cannot substitute one for the other. If you have csh (or tcsh) in another location, use that, or directly pass the script to csh: "csh scripts/makedbh". Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) From tim at opencircuitdesign.com Fri Apr 4 13:39:06 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: References: Message-ID: <47F683DA.70005@opencircuitdesign.com> Dear Aanjhan, > Also I changed the makedbh file to have /bin/sh > instead of /bin/csh. It is a common problem in a surprisingly large number of Linux distributions that /bin/csh has been obliterated. One of the first things I do when install a new OS is to find out where "tcsh" is (usually /bin/tcsh), then make a symbolic link: cd /bin ln -s csh tcsh so that "ls /bin/csh" should give you: lrwxrwxrwx 1 root root 4 Nov 29 2004 /bin/csh -> tcsh That will get makedbh working properly. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From aanjhan at gmail.com Sat Apr 5 12:46:55 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: <47F683DA.70005@opencircuitdesign.com> References: <47F683DA.70005@opencircuitdesign.com> Message-ID: Hi, On Sat, Apr 5, 2008 at 1:09 AM, R. Timothy Edwards wrote: > cd /bin > ln -s csh tcsh thanks. It works. I am planning to build a .deb for magic so that people using Debian based systems can directly install. Surprising that till date a .deb is not available. Regards, Aanjhan From john_g at cibolo.com Sat Apr 5 12:04:30 2008 From: john_g at cibolo.com (John Griessen) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: References: <47F683DA.70005@opencircuitdesign.com> Message-ID: <47F7A30E.8050702@cibolo.com> Aanjhan R wrote: > Hi, > > On Sat, Apr 5, 2008 at 1:09 AM, R. Timothy Edwards > wrote: >> cd /bin >> ln -s csh tcsh > > thanks. It works. I am planning to build a .deb for magic so that > people using Debian based systems can directly install. Surprising > that till date a .deb is not available. Thanks, That will help show people doing MEMS they can use a free tool. Will you be sending your deb along to debian for the distro? John Griessen From aanjhan at gmail.com Sun Apr 6 09:19:57 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: <47F7A30E.8050702@cibolo.com> References: <47F683DA.70005@opencircuitdesign.com> <47F7A30E.8050702@cibolo.com> Message-ID: Hi, On Sat, Apr 5, 2008 at 9:34 PM, John Griessen wrote: > Will you be sending your deb along to debian for the distro? Yes. ITP and launchpad bug request already filed. Just that I could not find time to do it until now. Reference : https://bugs.launchpad.net/ubuntu/+bug/185434 Regards, Aanjhan From chitlesh at gmail.com Sun Apr 6 19:45:39 2008 From: chitlesh at gmail.com (Chitlesh GOORAH) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: References: <47F683DA.70005@opencircuitdesign.com> <47F7A30E.8050702@cibolo.com> Message-ID: <13dbfe4f0804060945o4d0e9c32jf41cac3501905513@mail.gmail.com> On Sun, Apr 6, 2008 at 4:49 AM, Aanjhan R wrote: > Hi, > > > On Sat, Apr 5, 2008 at 9:34 PM, John Griessen wrote: > > Will you be sending your deb along to debian for the distro? > > Yes. ITP and launchpad bug request already filed. Just that I could > not find time to do it until now. > > Reference : > https://bugs.launchpad.net/ubuntu/+bug/185434 > > Regards, > Aanjhan > Hello there, This is not about distro bashing. Recently, I moved to Bruxelles, Belgium for my work and barely have time for maintaining "magic and friends" for Fedora Electronic Lab. If you feel, you might be able to help, I'll grant you the required access on the official fedora repositories as soon as possible. Magic , Xircuit and Netgen are already on FEL, but just need more love. thanks for understanding, Chitlesh From aanjhan at gmail.com Mon Apr 7 23:27:10 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Magic compilation issue with latest stable 7.5.129 In-Reply-To: <13dbfe4f0804060945o4d0e9c32jf41cac3501905513@mail.gmail.com> References: <47F683DA.70005@opencircuitdesign.com> <47F7A30E.8050702@cibolo.com> <13dbfe4f0804060945o4d0e9c32jf41cac3501905513@mail.gmail.com> Message-ID: Hi, On Sun, Apr 6, 2008 at 10:15 PM, Chitlesh GOORAH wrote: > If you feel, you might be able to help, I'll grant you the required > access on the official fedora repositories as soon as possible. I will be very happy to help out. But I have no clue on rpm packaging and will take time learning it. If you can point me to any tutorials online it will be easy for me. > Magic , Xircuit and Netgen are already on FEL, but just need more love. I am game, but just will take some time to get used to rpm stuff. And also i dont run any RH based distro. Will have to setup a system for that first. Btw, I guess its better to take this discussion off-list as its not anymore related to Magic-devel IMO. Regards, Aanjhan From chenycs at tpts5.seed.net.tw Wed Apr 9 09:29:13 2008 From: chenycs at tpts5.seed.net.tw (=?big5?B?s6+lw7Tc?=) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] DRC bug Message-ID: <007f01c899d8$bd4a54d0$96cb09c0@HP86461888030> Hello all, I have find a bug in widespacing check DRC. "widespacing allMetal1 375 allMetal1 28", in this sentence the wide metal define must less equal than 375, if greater than 375 it dosen't work. Thanks, Arthur-------------- next part -------------- An HTML attachment was scrubbed... URL: http://vlsi.csl.cornell.edu/pipermail/magic-dev/attachments/20080409/ec5beda8/attachment.html From chenycs at tpts5.seed.net.tw Wed Apr 9 11:44:46 2008 From: chenycs at tpts5.seed.net.tw (=?big5?B?s6+lw7Tc?=) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] DRC bug Message-ID: <00aa01c899eb$b6ad8ad0$96cb09c0@HP86461888030> Hello all, I'm using Magic 7.5.129 and I find a bug in widespacing check DRC. "widespacing allMetal1 375 allMetal1 28", in this sentence the wide metal define must less equal than 375, if greater than 375 it dosen't work. Thanks, Arthur From timothy_edwards at multigig.com Tue Apr 8 22:59:04 2008 From: timothy_edwards at multigig.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] DRC bug Message-ID: <1207717144.5084@flurry.he.net> Dear Arthur, > I'm using Magic 7.5.129 and I find a bug in widespacing check DRC. > > "widespacing allMetal1 375 allMetal1 28", > > in this sentence the wide metal define must less equal than 375, > if greater than 375 it dosen't work. The widespacing rule works for me (in my compilation of 7.5.129). Remember that the rule must be followed by "touching_ok" or "touching_illegal", just like the spacing rule. If this is not working for you, then I will need to see the complete rule, as well as the alias definition for allMetal1, since both may impact the way the rule is interpreted. I made some major changes to the DRC rules recently, and it is always possible that the layer parsing is broken under some condition that I have not tested. I can only say that I used: aliases allm1 *m1,rmetal1 end with the rules spacing allm1 allm1 16 touching_ok \ "allm1 spacing to allm1 is 16 (test)" widespacing allm1 375 allm1 28 touching_ok \ "Spacing from m1 to wide (>375) m1 is 28 (test)" and this worked as expected: the spacing rule between two metal1 lines is 16 units, unless one of the metal1 lines is larger than 375 units, in which case the spacing rule is increased to 28. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim.edwards@multigig.com | | MultiGiG, Inc. | web: http://www.multigig.com | | 100 Enterprise Way Suite A-3 | phone: (831) 621-3283 | | Scotts Valley, CA 95066 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From n.schutten at sts.nl Fri Apr 11 11:11:02 2008 From: n.schutten at sts.nl (Niels Schutten) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Error running Magic on Win XP and Cygwin Message-ID: <6B2D07A0A827A1419C4435A40811C5A545DC17@PDC.NETWERK.local> Hi Brad, I came across your posted message http://vlsi.cornell.edu/pipermail/magic-dev/2007/000392.html about the tclmagic.dll library not being loaded. I am having the same problem. Have you been able to resolve yours? Thanks and regards, Niels -- Niels Schutten VP Engineering & Operations STS B.V. Zekeringstraat 40 1014 BT AMSTERDAM The Netherlands tel: +31 20 420 4200 fax: +31 20 420 9652 email: n.schutten@sts.nl web: http://www.sts.nl ************************************************************************ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.This information is provided "as is" without any express or implied warranty of any kind, including but not limited to warranties of merchantability, non-infringement of intellectual property, or fitness for any particular purpose. In no event shall WSS, its management and/or employees, or its affiliates, or its suppliers be liable for any damages whatsoever arising out of the use of, or inability to use the materials. WSS, its affiliates and its suppliers further do not warrant the accuracy or completeness of the information, text, graphics, or other items contained within these materials. WSS, its affiliates and its suppliers may make changes to these materials, or the products described within at any time, without notice. ************************************************************************ * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://vlsi.csl.cornell.edu/pipermail/magic-dev/attachments/20080411/44111dff/attachment.html From slavko1001 at hotmail.com Mon Apr 14 23:07:10 2008 From: slavko1001 at hotmail.com (Radovc Slavko) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Instalation Magic and IRSIM on Ubuntu 7.10 Message-ID: Can you help me about this? I tried to do it but I could't done it. I compiled TCL/TK but when I try to install MAGIC 7.5.129 it stop me at point of make with errors: errors and warnings logged in file make.log --- making modules --- compiling graphics/grTOGL3.o grTOGL3.c:16:20: error: GL/glu.h: No such file or directory --- making Tcl shared libraries make[2]: *** No rule to make target `../graphics/libgraphics.o', needed by `tclmagic.so'. Stop. and make install with errors: --- installing executable to /usr/local/bin --- installing runtime files to /usr/local/lib make[2]: *** No rule to make target `../graphics/libgraphics.o', needed by `tclmagic.so'. Stop. If you have any tutuorial or installation gide can you send me. I will very appreciated that. Thanky in fowred for your time. _________________________________________________________________ More immediate than e-mail? Get instant access with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008 From nestorj at lafayette.edu Tue Apr 22 19:07:11 2008 From: nestorj at lafayette.edu (John Nestor) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Importing GDS from Astro into Magic? Message-ID: Hey Magic-Dev Folks, Has anyone tried importing a stream file generated by Synopsys Astro Place&Route into Magic? I'm using the Oklahoma State University flow to generate a layout and am trying to read it back into Magic, and I'm encountering some issues: Hope you are doing well. I've been trying out the Astro flow for the 0.5um standard cells. It seems to work OK creating the tutorial example, but I'm having some issues reading the resulting GDS file back into Magic. Is there a preprocessing step that I'm not aware of? 1. The gridsize is changed when I read the stream file back into Magic to be 2 lambda. Is this due to the fact that Astro puts things on half lambdas? Maybe this is a feature rather than an issue. 2. The top level cell is empty. I can find the necessary logic in a subcell called "toppo". 3. Looking at the "toppo" subcell, there are DRC errors because adjacent cells are placed 1 lambda apart and the well spacing rule is violated. 4. The "via" subcells $$M2_M1, $$M3_M2, $$M2_M1_1500_1500_3_1 and $$M2_M1_1500_1500_3_3 are not getting instantiated properly in the "toppo" cell and connectivity between layers is lost at these points. Does magic have issues with cell names that start with "$$"? If anyone else has encoutered these issues or has suggestions how to deal with them, I'd appreciate hearing from you. I'm using Magic 7.4 rev 34. Thanks, John -- John Nestor, Associate Professor ECE Department Lafayette College Easton, PA 18042 nestorj@lafayette.edu http://foghorn.cadlab.lafayette.edu/~nestorj From tim at opencircuitdesign.com Tue Apr 22 17:25:11 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:10 2008 Subject: [Magic-dev] Importing GDS from Astro into Magic? In-Reply-To: References: Message-ID: <480E73D7.7090803@opencircuitdesign.com> Dear John, > Has anyone tried importing a stream file generated by Synopsys Astro > Place&Route into Magic? I'm using the Oklahoma State University flow to > generate a layout and am trying to read it back into Magic, and I'm > encountering some issues: No, but I do have extensive experience importing various 3rd-party GDS files into Magic, and the issues are generally the same. > 1. The gridsize is changed when I read the stream file back into Magic to be > 2 lambda. Is this due to the fact that Astro puts things on half lambdas? > Maybe this is a feature rather than an issue. Sometimes if some non-physical geometry is placed on a half-lambda grid, Magic will rescale to accomodate it, even though no final geometry in Magic is on the half-lambda grid. If this is the case, then use "gds rescale false" to prevent Magic from changing its grid size during read-in. > 2. The top level cell is empty. I can find the necessary logic > in a subcell called "toppo". This is just a feature of GDS files. They don't have top-level cells like CIF files do. If magic writes a GDS file, it knows how to read it back in such that the top-level cell is loaded into the window. But it can't do that with 3rd-party GDS files. You can, however, do the command "cellname top" to find out which cell or cells is on the top of the hierarchy, so you don't have to search around for it blindly. > 3. Looking at the "toppo" subcell, there are DRC errors because adjacent > cells are placed 1 lambda apart and the well spacing rule is violated. There are a couple of choices here---(1) try to get the placer to abut the cells properly, instead of inserting space, and (2) don't parse the nwell in a GDS read-in. In this case, I would expect that you really ought not to have gaps between the nwells created by the placement. But, where you know that the standard cells are correct, just ignore the nwell and let magic auto-generate it on GDS output, at which time the layers will get merged together by the grow-shrink rules. What I do for standard-cell read-in is to use the "gds readonly true" option for the standard cells themselves, and I sometimes read in a very limited set of layers so that I don't get DRC violations within the cell or between cells due to technicalities of the way the "cifinput" section of the Magic techfile is written. You should only do this if you're sure that the standard cell set is correct and all errors are false positives. The "gds readonly true" preserves the GDS database for the cells read in under that setting, such that when the cells are written back out to a GDS file, the original layout is preserved exactly. This prevents Magic from screwing up known good 3rd-party layout. > 4. The "via" subcells $$M2_M1, $$M3_M2, $$M2_M1_1500_1500_3_1 and > $$M2_M1_1500_1500_3_3 are not getting instantiated properly in the "toppo" > cell and connectivity between layers is lost at these points. Does magic > have issues with cell names that start with "$$"? It's not supposed to. Tcl/Tk treats "$" as a variable name indicator, but because Cadence uses this nomenclature a lot, I have specifically written code to check for the double-dollar-sign. You might want to check Magic version 7.5 (the current stable distribution), which is more up-to-date than 7.4. The more likely possibility is that the "cifinput" section expects a via size that has a larger overlap than the subcells created by the router. This is often the case where the Magic rules have been written for a more relaxed set of design rules, and the router uses a more aggressive set of rules to squeeze out every last nanometer of available space. The cifinput routine may simply decide that there is not enough space in the cell to generate a contact, and therefore fail to generate one, leaving an open circuit where there should be a contact cut. The solution to this is to rewrite the cifinput rules, and possibly the DRC deck as well, if you don't want the tighter rules showing up thousands of DRC violations in the design. If you have any remaining issues, send me some layout and the corresponding techfile, and I can figure out what's going wrong with it. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From Mark.Martin at jhuapl.edu Tue Apr 22 23:11:45 2008 From: Mark.Martin at jhuapl.edu (Martin, Mark) Date: Thu Oct 30 14:34:11 2008 Subject: [Magic-dev] Importing GDS from Astro into Magic? References: <480E73D7.7090803@opencircuitdesign.com> Message-ID: <2B7AE358F7B72040879A71F946D99CA701C111F9@aplesjustice.dom1.jhuapl.edu> John and Tim I have imported Astro gds into magic with some success, but the issues you mention are common. 1. The Astro P&R tool will snap things on the .5 grid, usuallly because it puts the contacts center on the wire width. I just accept it and move on. 2. You should be able to adjust the cell spacing, or add a fill cell. It is also possible to have Astro paint a well across the strip. I don't use the tool myself so I do not know the details. Tim's suggestion is probably the easiest 3. Magic 7.5.120 seems to handle the $$ file names OK when reading in the gds. The issue is once you save, quit , restart magic. Magic doesn't seem to be able to find the files starting with $$. I ran across this 10 minutes ago! So it seems the issue how load passes the string to the OS. MY quick fix will be to rename the cells and corresponding magic files. Another fix would be to flatten the wires/vias. Mark -----Original Message----- From: magic-dev-bounces@csl.cornell.edu on behalf of R. Timothy Edwards Sent: Tue 4/22/2008 7:25 PM To: John Nestor Cc: magic-dev@csl.cornell.edu Subject: Re: [Magic-dev] Importing GDS from Astro into Magic? Dear John, > Has anyone tried importing a stream file generated by Synopsys Astro > Place&Route into Magic? I'm using the Oklahoma State University flow to > generate a layout and am trying to read it back into Magic, and I'm > encountering some issues: No, but I do have extensive experience importing various 3rd-party GDS files into Magic, and the issues are generally the same. > 1. The gridsize is changed when I read the stream file back into Magic to be > 2 lambda. Is this due to the fact that Astro puts things on half lambdas? > Maybe this is a feature rather than an issue. Sometimes if some non-physical geometry is placed on a half-lambda grid, Magic will rescale to accomodate it, even though no final geometry in Magic is on the half-lambda grid. If this is the case, then use "gds rescale false" to prevent Magic from changing its grid size during read-in. > 2. The top level cell is empty. I can find the necessary logic > in a subcell called "toppo". This is just a feature of GDS files. They don't have top-level cells like CIF files do. If magic writes a GDS file, it knows how to read it back in such that the top-level cell is loaded into the window. But it can't do that with 3rd-party GDS files. You can, however, do the command "cellname top" to find out which cell or cells is on the top of the hierarchy, so you don't have to search around for it blindly. > 3. Looking at the "toppo" subcell, there are DRC errors because adjacent > cells are placed 1 lambda apart and the well spacing rule is violated. There are a couple of choices here---(1) try to get the placer to abut the cells properly, instead of inserting space, and (2) don't parse the nwell in a GDS read-in. In this case, I would expect that you really ought not to have gaps between the nwells created by the placement. But, where you know that the standard cells are correct, just ignore the nwell and let magic auto-generate it on GDS output, at which time the layers will get merged together by the grow-shrink rules. What I do for standard-cell read-in is to use the "gds readonly true" option for the standard cells themselves, and I sometimes read in a very limited set of layers so that I don't get DRC violations within the cell or between cells due to technicalities of the way the "cifinput" section of the Magic techfile is written. You should only do this if you're sure that the standard cell set is correct and all errors are false positives. The "gds readonly true" preserves the GDS database for the cells read in under that setting, such that when the cells are written back out to a GDS file, the original layout is preserved exactly. This prevents Magic from screwing up known good 3rd-party layout. > 4. The "via" subcells $$M2_M1, $$M3_M2, $$M2_M1_1500_1500_3_1 and > $$M2_M1_1500_1500_3_3 are not getting instantiated properly in the "toppo" > cell and connectivity between layers is lost at these points. Does magic > have issues with cell names that start with "$$"? It's not supposed to. Tcl/Tk treats "$" as a variable name indicator, but because Cadence uses this nomenclature a lot, I have specifically written code to check for the double-dollar-sign. You might want to check Magic version 7.5 (the current stable distribution), which is more up-to-date than 7.4. The more likely possibility is that the "cifinput" section expects a via size that has a larger overlap than the subcells created by the router. This is often the case where the Magic rules have been written for a more relaxed set of design rules, and the router uses a more aggressive set of rules to squeeze out every last nanometer of available space. The cifinput routine may simply decide that there is not enough space in the cell to generate a contact, and therefore fail to generate one, leaving an open circuit where there should be a contact cut. The solution to this is to rewrite the cifinput rules, and possibly the DRC deck as well, if you don't want the tighter rules showing up thousands of DRC violations in the design. If you have any remaining issues, send me some layout and the corresponding techfile, and I can figure out what's going wrong with it. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ _______________________________________________ magic-dev mailing list magic-dev@vlsi.cornell.edu http://vlsi.csl.cornell.edu/mailman/listinfo/magic-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://vlsi.csl.cornell.edu/pipermail/magic-dev/attachments/20080422/dea2cfb4/attachment.html From tim at opencircuitdesign.com Wed Apr 23 00:13:48 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:11 2008 Subject: [Magic-dev] Importing GDS from Astro into Magic? In-Reply-To: <2B7AE358F7B72040879A71F946D99CA701C111F9@aplesjustice.dom1.jhuapl.edu> References: <480E73D7.7090803@opencircuitdesign.com> <2B7AE358F7B72040879A71F946D99CA701C111F9@aplesjustice.dom1.jhuapl.edu> Message-ID: <480ED39C.7080203@opencircuitdesign.com> Dear Mark and John, > 3. Magic 7.5.120 seems to handle the $$ file names OK when reading in the gds. The issue > is once you save, quit , restart magic. Magic doesn't seem to be able to find the files > starting with $$. I ran across this 10 minutes ago! So it seems the issue how load > passes the string to the OS. I should probably clarify that as long as Magic is running under Tcl/Tk, the Tcl/Tk interpreter *will* attempt to convert anything beginning with "$" into a variable if it is typed on the command line. Thus, once you have created such a cell name, you will have to start referring to it with backslash character escapes (e.g., "\$\$M2_M1"). This is, of course, all Cadence's fault. > MY quick fix will be to rename the cells and corresponding magic files. > Another fix would be to flatten the wires/vias. Which reminds me to mention another useful option I added to the "gds" command, which is "gds flatten on". This will check the GDS input for cells with a trivial amount of geometry in them (defined as less than 10 rectangles) and flatten them on input. By the way, if you want to *generate* these kind of contacts (which are widely used because the array record in GDS is very compact, but only subcells can be arrayed), use the option "gds contacts true". And while we're on the subject of obscure GDS options in Magic, don't miss the option "gds merge true", which compiles all the tiles of Magic's database into polygons. This is very helpful when transferring data between Magic and other EDA tools, none of which tend to deal well with the millions of fractured tiles that Magic tends to output (we had a particular problem with exporting geometry to the field-solver HFSS). It's a bit slow, though. I was thinking about offering $100 to anyone who could speed up the algorithm by a factor of 2. . . ---Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From Mark.Martin at jhuapl.edu Wed Apr 23 09:17:37 2008 From: Mark.Martin at jhuapl.edu (Martin, Mark) Date: Thu Oct 30 14:34:11 2008 Subject: [Magic-dev] Importing GDS from Astro into Magic? In-Reply-To: <480ED39C.7080203@opencircuitdesign.com> References: <480E73D7.7090803@opencircuitdesign.com> <2B7AE358F7B72040879A71F946D99CA701C111F9@aplesjustice.dom1.jhuapl.edu> <480ED39C.7080203@opencircuitdesign.com> Message-ID: <2B7AE358F7B72040879A71F946D99CA70568F1DE@aplesjustice.dom1.jhuapl.edu> Tim, > > > 3. Magic 7.5.120 seems to handle the $$ file names OK > when reading > > in the gds. The issue is once you save, quit , restart > magic. Magic > > doesn't seem to be able to find the files starting with $$. I ran > > across this 10 minutes ago! So it seems the issue how load > passes the string to the OS. > > I should probably clarify that as long as Magic is running > under Tcl/Tk, the Tcl/Tk interpreter *will* attempt to > convert anything beginning with "$" > into a variable if it is typed on the command line. Thus, > once you have created such a cell name, you will have to > start referring to it with backslash character escapes (e.g., > "\$\$M2_M1"). This is, of course, all Cadence's fault. This makes perfect sense, but the issue I have is that if I load the main cell, then try to expand, magic can't find the files to load them into memory, presumably because it is misinterpreting file name as a variable. I will try the gds flatten on option, I think this will also solve my other issue of moderate amounts of drc violations that magic sees that aren't really there. - Mark > From aanjhan at gmail.com Fri Apr 25 08:44:42 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:11 2008 Subject: [Magic-dev] Problem in generating scmos.tech Message-ID: Hi All, I have uploaded a initial .deb for Magic in the link below. http://aanjhan.unixpod.com/packages/magic_7.5.129-1_i386.deb The only problem with this deb now is that magic cannot be started with scmos technology files. the reason is the make install for some reason generates a blank scmos.tech file. The other two technologies minimum and gdsquery works absolutely fine. The error while building the debianised package is as follows: --- installing executable to /tmp/buildd/magic-7.5.129/debian/magic/usr/bin --- installing runtime files to /tmp/buildd/magic-7.5.129/debian/magic/usr/lib i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because linking not done i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because linking not done i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because linking not done i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because linking not done This leads to a blank scmos.tech file generation. But if I build the magic package directly from the src tarball without debianising it, it works fine. It would be great if someone gives me a clue as to what is going wrong here. I will be more than happy to provide any further information that is necessary to resolve the issue. Thanks and Regards, Aanjhan From fang at csl.cornell.edu Thu Apr 24 23:31:39 2008 From: fang at csl.cornell.edu (David Fang) Date: Thu Oct 30 14:34:11 2008 Subject: [Magic-dev] Problem in generating scmos.tech In-Reply-To: References: Message-ID: <20080424222712.N30178@shannon.csl.cornell.edu> > The error while building the debianised package is as follows: > > --- installing executable to /tmp/buildd/magic-7.5.129/debian/magic/usr/bin > --- installing runtime files to /tmp/buildd/magic-7.5.129/debian/magic/usr/lib > i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because > linking not done > i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because > linking not done > i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because > linking not done > i486-linux-gnu-gcc: scmos.tech.in: linker input file unused because > linking not done > > This leads to a blank scmos.tech file generation. But if I build the > magic package directly from the src tarball without debianising it, it > works fine. It would be great if someone gives me a clue as to what is > going wrong here. I will be more than happy to provide any further > information that is necessary to resolve the issue. Hi, What I've done is replace the generating command for scmos.tech in scmos/Makefile (gcc ...) with "cpp -traditional -P", somehow the old options being passed to "gcc ..." were incorrect. I don't remember if "gcc -E ..." (-E means preprocess-only) works, but I didn't see any reason to invoke gcc if only the preprocessor was used. (This predates magic 7.1.) HTH, David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) From tim.edwards at multigig.com Fri Apr 25 11:45:56 2008 From: tim.edwards at multigig.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:11 2008 Subject: [Magic-dev] Re: further problems building on OS X In-Reply-To: <4AF88D72-BC92-431D-A88B-CCE7E5577CEA@email.it> References: <4AF88D72-BC92-431D-A88B-CCE7E5577CEA@email.it> Message-ID: <481218D4.3000506@multigig.com> Dear Andrea, > I run make in main tree and got no errors so I tought it was fine until > I noticed there were no ext2sim nor ext2spice in shell path. > > Digging in I saw that they have been migrated in tcl space so they could > be just accessed from magic console using exttosim and exttospice, > unluckily I still got an error while doing it. > > My proof of concept is: run "magic foo.mag" draw a 4x4 m1 rect and then > type ":extract all" and ":exttosim foo" and I got a > > "dlopen(/opt/local/lib/magic/tcl/exttosim.dylib, 6): Symbol not found: > _ArgStr > Referenced from: /opt/local/lib/magic/tcl/exttosim.dylib > Expected in: flat namespace" > > Is this a known bug? No, it's not. The .dylib files should be compiled using the symbol map table in magic/symbol.map. This file sets the routine name ArgStr() to be global, so that the call in ext2sim.dylib can be linked to the subroutine definition in tclmagic.dylib when ext2sim.dylib is loaded (along with a bunch of other variable and subroutine symbol names). I'm not very familiar with the OS-X linker, but in Linux, the linker flags are defined (in file defs.mak) as: LDDL_FLAGS = -shared -Wl,-soname,$@ \ -Wl,--version-script=${MAGICDIR}/magic/symbol.map Others who use OS-X and subscribe to the magic-dev mailing list may have more insight into this problem, so I'm CC'ing this message to magic-dev. > Why doesn't "make all" build separate cli ext2sim and ext2spice? > I tried to run "make mains" but I got several errors when linking to > libutils.a . Adding -ltk and -ltcl to ./ext2sim/Makefile reduced error > lines number but there are still a lot of unreferenced symbols in > libutils.a , has anyone reported this? It's my fault for not substituting a script for the two executables. The idea is that making ext2sim and ext2spice loadable modules means that both programs can make direct use of the techfile paramters rather than obtain all their information from the .ext file. But, you can make simple scripts that call magic in "batch mode" (magic -dnull -noconsole) that will be equivalent replacements for the standalone ext2sim and ext2spice executables. "make mains" is part of the non-Tcl compile. I recommend resolving the problems with Tcl/Tk rather than reverting to the non-Tcl version. However, if you want to do that, be sure to do "make clean" first, then re-configure with "--without-tcl". Failure to do "make clean" will result in lots of error messages. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim.edwards@multigig.com | | MultiGiG, Inc. | web: http://www.multigig.com | | 100 Enterprise Way, Suite A-3 | phone: (831) 621-3283 | | Scotts Valley, CA 95066 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From IlanB at raysat.com Fri Apr 25 12:29:29 2008 From: IlanB at raysat.com (Ilan Barak) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic trouble on Suse10.3 64bit Message-ID: <4BD3F4EEA2F6E349A92780432B394D518934C6@exch-srv.raysat.co.il> I apologize for the long list, and hope it will help to explain may problem. An example of the corrupt magic screen can be seen at http://barak.hopto.org/ilan/temp/x1.jpg I am having trouble running (and configuring ) Magic on Suse 10.3 Linux x_64 (amd) I have tcl installed ilanlinux:/home/ilanb/downloads/magic # rpm -qa | grep tcl tcl-32bit-8.4.15-22 tclx-8.4-406 tcl-8.4.15-22 tcllib-1.9-53 tcl-devel-8.4.15-22 and Tk tk-devel-8.4.15-25.3 tk-8.4.15-25 and blt blt-2.4z-301 when I run ./configure I get checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for library containing strerror... none required checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for gm4... no checking for gnum4... no checking for m4... /usr/bin/m4 checking for ld used by GCC... /usr/x86_64-suse-linux/bin/ld checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for void *... yes checking size of void *... 8 checking for unsigned int... yes checking size of unsigned int... 4 checking for unsigned long... yes checking size of unsigned long... 8 checking for unsigned long long... yes checking size of unsigned long long... 8 checking whether byte ordering is bigendian... no checking for ANSI C header files... (cached) yes checking for setenv... yes checking for putenv... yes checking for vfork... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking param.h usability... no checking param.h presence... no checking for param.h... no checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking for va_copy... yes checking for __va_copy... yes checking for gcore... no checking for csh... /usr/bin/csh checking for X... libraries /usr/lib64, headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for XOpenDevice in -lXi... yes checking for XmuInternAtom in -lXmu... yes checking for XextFindDisplay in -lXext... yes checking for tclConfig.sh... /usr/local/lib/tclConfig.sh checking for tkConfig.sh... /usr/local/lib/tkConfig.sh checking for wish executable... /usr/local/bin/wish8.4 checking for tclsh executable... /usr/local/bin/tclsh8.4 checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for glXCreateContext in -lGL... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes configure: creating ./config.status config.status: creating defs.mak ----------------------------------------------------------- Configuration Summary (principle requirements): X11: yes OpenGL: yes Tcl/Tk: yes BLT: no Tcl/Tk magic uses the BLT package to create a tree diagram of the cell hierarchy in a design. Without it, this option is unavailable. Consider installing the BLT package. ----------------------------------------------------------- Use 'make' to compile and 'make install' to install. Errors may not be printed to stdout: see files 'make.log' and 'install.log' for complete error summary. ----------------------------------------------------------- I make and make install OK ilanb@ilanlinux:~/downloads/magic> make --- errors and warnings logged in file make.log --- making modules --- making Tcl shared libraries ilanb@ilanlinux:~/downloads/magic> su Password: ilanlinux:/home/ilanb/downloads/magic # make install --- installing executable to /usr/local/bin --- installing runtime files to /usr/local/lib ilanlinux:/home/ilanb/downloads/magic # but magic crashes due to wish8.5 in tkcon.tcl /usr/local/lib/magic/tcl/tkcon.tcl: line 3: /usr/local/bin/wish8.5: No such file or directory /usr/local/lib/magic/tcl/tkcon.tcl: line 3: exec: /usr/local/bin/wish8.5: cannot execute: No such file or directory When I correct the line in magic MAGIC_WISH=/usr/local/bin/wish8.5 to wish8.4 magic starts but the layout window is empty, no tools or menuse. The console shows: loading history file ... 0 events added error in slave eval: couldn't load file "/usr/local/lib/magic/tcl/tclmagic.so": /usr/local/lib/magic/tcl/tclmagic.so: undefined symbol: Tcl_PkgInitStubsCheck Main console display active (Tcl8.4.19 / Tk8.4.19) (magic-7.5.131) 1 % Can anyone help Ilan Barak -------------- next part -------------- An HTML attachment was scrubbed... URL: http://vlsi.csl.cornell.edu/pipermail/magic-dev/attachments/20080425/2527e61b/attachment.html From aanjhan at gmail.com Sat Apr 26 14:01:57 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Problem in generating scmos.tech In-Reply-To: <20080424222712.N30178@shannon.csl.cornell.edu> References: <20080424222712.N30178@shannon.csl.cornell.edu> Message-ID: Hi, On Fri, Apr 25, 2008 at 8:01 AM, David Fang wrote: > What I've done is replace the generating command for scmos.tech in > scmos/Makefile (gcc ...) with "cpp -traditional -P", somehow the old options > being passed to "gcc ..." were incorrect. I don't remember if "gcc -E ..." > (-E means preprocess-only) works, but I didn't see any reason to invoke gcc > if only the preprocessor was used. (This predates magic 7.1.) This works. thanks a lot. Regards, Aanjhan From aanjhan at gmail.com Sat Apr 26 14:06:06 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] spice2sim man page Message-ID: Hi Folks, I am finding that spice2sim is also a binary package that comes in along with magic src tarball. But I am unable to find a corresponding manpage for it. Is there one? Debian based distros do not accept binaries without manpages as a matter of good practice. Or can I get the Usage guide of spice2sim from some link so that I can write a manpage and contribute back? I googled but couldnt find much info. I am not sure if I missed something here. Thanks in Advance. Regards, -- Aanjhan From tim at opencircuitdesign.com Sat Apr 26 02:16:32 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] spice2sim man page In-Reply-To: References: Message-ID: <4812E4E0.8000104@opencircuitdesign.com> Dear Aanjhan, > I am finding that spice2sim is also a binary package that comes in > along with magic src tarball. But I am unable to find a corresponding > manpage for it. Is there one? Debian based distros do not accept > binaries without manpages as a matter of good practice. > > Or can I get the Usage guide of spice2sim from some link so that I can > write a manpage and contribute back? I googled but couldnt find much > info. I am not sure if I missed something here. Technically, spice2sim is a script (awk script), not a binary. The summary usage is really just what's printed on the first comment line, which is: "convert an ext2spice produced file to a .sim file for debugging" It looks like it takes no arguments, and expects input from stdin and writes output to stdout. Typical usage would be: spice2sim < circuit.spice > circuit.sim However, please note that (1) this file is outdated with respect to bipolar transistors as well as semiconductor resistors and capacitors that Magic and IRSIM can handle, and (2) since from Magic you can get either format for output, converting between the two is generally unnecessary, and (3) if you have a Magic-derived SPICE file without a layout, "netgen" will better handle the conversion. In other words, if you leave "spice2sim" out of the Debian distro, nobody will care, and probably nobody will even notice. ---Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From tim at opencircuitdesign.com Sat Apr 26 11:05:01 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Re: further problems building on OS X In-Reply-To: <54D30FEB-442A-4AB2-B22B-FCA67DC2DC25@email.it> References: <4AF88D72-BC92-431D-A88B-CCE7E5577CEA@email.it> <481218D4.3000506@multigig.com> <54D30FEB-442A-4AB2-B22B-FCA67DC2DC25@email.it> Message-ID: <481360BD.5070305@opencircuitdesign.com> Dear Andrea, > I've added "libutils.o" to the exttosim.dylib build command, this way > the ArgStr symbol is defined into the library, but I got an error for a > symbol defined into libcmwind, I understand there's something wront at > the very base. This would *not* be the proper approach, since the dynamic libraries should not be duplicating routines of other libraries that will be present when they are linked; and since libutils will use variables and routines from other libraries in tclmagic.dylib, you will eventually have to link to everything at the same time (i.e., a static library) to get it to work. The solution is giving the right options to the linker, but I don't know enough about OS-X to know what changes are needed to the options, or why it doesn't work now. > I noticed symbol.map contents has a "MAGIC_7.3" section, is that correct? This is clearly wrong and should be changed. On the other hand, I've never seen it have any effect on the compilation under Linux. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From aanjhan at gmail.com Sun Apr 27 11:22:49 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic: Licensing and embedding readline libraries Message-ID: Hi Magic Devels, I am again back with more questions. A debianised package has been uploaded at debian mentors for review so that it could get into Debian soonish. There have been a couple of review comments which I would need your help to resolve. 1. The package as such seems to be licensed under Berkeley License with an embedded source copy of GNU Readline which is GPL. It would be great if I can get hold of a proper license notice for MAGIC. 2. There seem to be some issue with embedding copies of readline src in the package itself. Being an upstream developer of GNuSim8085 myself, I completely understand that this would make the package completely independent/self contained. But do you guys suggest any other way out. Like checking for readline in configure or some such? I am not sure whether I am talking sense but if we are able to remove this embedding it would be much easier to get the package into Debian/Ubuntu soonish. For the complete thread of the review comments: http://news.gmane.org/gmane.linux.debian.devel.mentors (check the one with subject RFS: magic) Debian Upload: http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=magic Ubuntu Hardy heron users can install magic now by adding the below lines to their sources.list file and doing a sudo apt-get update and installing the application. deb http://ppa.launchpad.net/aanjhan/ubuntu hardy main deb-src http://ppa.launchpad.net/aanjhan/ubuntu hardy main Review comments welcome! and thanks for all the support you people have provided. Looking forward to the same in the future too. -- Aanjhan ------------ http://www.tuxmaniac.com From fang at csl.cornell.edu Sun Apr 27 02:11:12 2008 From: fang at csl.cornell.edu (David Fang) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic: Licensing and embedding readline libraries In-Reply-To: References: Message-ID: <20080427010725.W39713@shannon.csl.cornell.edu> > I am again back with more questions. A debianised package has been > uploaded at debian mentors for review so that it could get into Debian > soonish. There have been a couple of review comments which I would > need your help to resolve. > > 1. The package as such seems to be licensed under Berkeley License > with an embedded source copy of GNU Readline which is GPL. It would be > great if I can get hold of a proper license notice for MAGIC. > > 2. There seem to be some issue with embedding copies of readline src > in the package itself. Being an upstream developer of GNuSim8085 > myself, I completely understand that this would make the package > completely independent/self contained. But do you guys suggest any > other way out. Like checking for readline in configure or some such? I > am not sure whether I am talking sense but if we are able to remove > this embedding it would be much easier to get the package into > Debian/Ubuntu soonish. Hi, You'll have to patch or hand-edit the build to skip recursing into the readline subtree and preserve the LDFLAG for -lreadline. I have old instructions here: http://www.csl.cornell.edu/~fang/sw/magic-7.1-osx.html These pertain to magic-7.1, but the newer versions still use "defs.mak". [That will be fixed eventually... maybe soon.] Hope you can find an appropriate solution from these notes. > For the complete thread of the review comments: > http://news.gmane.org/gmane.linux.debian.devel.mentors (check the one > with subject RFS: magic) > Debian Upload: http://mentors.debian.net/cgi-bin/maintainer-packages?action=details;package=magic Thanks for taking the initiative on the debian packaging. Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) From aanjhan at gmail.com Sun Apr 27 18:17:59 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic: Licensing and embedding readline libraries In-Reply-To: <20080427010725.W39713@shannon.csl.cornell.edu> References: <20080427010725.W39713@shannon.csl.cornell.edu> Message-ID: Hi David, On Sun, Apr 27, 2008 at 10:41 AM, David Fang wrote: > You'll have to patch or hand-edit the build to skip recursing into > the readline subtree and preserve the LDFLAG for -lreadline. I have old > instructions here: > > http://www.csl.cornell.edu/~fang/sw/magic-7.1-osx.html Thanks for the tips. It would be great if someone throws light on the licensing of Magic? It seems to be BSD Licensed from what I noticed but there is no clear LICENSE file. But in fedora I see the license for MAGIC mentioned as GPLv2. I am confused. Thanks David once again for those notes. I am going through it and will try to sort things out. Regards, Aanjhan From tim at opencircuitdesign.com Sun Apr 27 09:16:26 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic: Licensing and embedding readline libraries In-Reply-To: References: <20080427010725.W39713@shannon.csl.cornell.edu> Message-ID: <481498CA.9060105@opencircuitdesign.com> Dear Aanjhan, > Thanks for the tips. It would be great if someone throws light on the > licensing of Magic? It seems to be BSD Licensed from what I noticed > but there is no clear LICENSE file. But in fedora I see the license > for MAGIC mentioned as GPLv2. I am confused. Any mention of GPL in the Fedora package must be in error. I have never been able to tell exactly what license Magic falls under, but I would assume it to be a BSD license. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From aanjhan at gmail.com Sun Apr 27 23:21:58 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic: Licensing and embedding readline libraries In-Reply-To: <481498CA.9060105@opencircuitdesign.com> References: <20080427010725.W39713@shannon.csl.cornell.edu> <481498CA.9060105@opencircuitdesign.com> Message-ID: Dear Tim, On Sun, Apr 27, 2008 at 8:46 PM, R. Timothy Edwards wrote: > Any mention of GPL in the Fedora package must be in error. I have > never been able to tell exactly what license Magic falls under, but > I would assume it to be a BSD license. Again here we have the question of whether it is the "Original BSD" License or "modified BSD" license. Because according to http://www.gnu.org/philosophy/license-list.html the original BSD license is *not* compatible with GPL but the modified one is. If MAGIC was licensed under Modified BSD (or rather 3 clause BSD License) then there should not be any issue with the Debian based distros including them as it is. Else since a source copy of GNU Readline is embedded in the upstream tarball which is licensed under GPL and the actual src of the package (if licensed under "Original BSD") becomes incompatible. The only way out is to hack in getting the package use libreadline of the distro or some such. Personally I want to get these valuable packages into Debian based distros without getting into too much of all these, but sometimes one has to respect the policies of the Distribution as well. Hope you understand and not take it the wrong way. I will try my level best to sort things out. Thanks Tim for the clarity you offered. I am still wondering how Fedora resolved this license conflict. Thanks and Regards, Aanjhan From aanjhan at gmail.com Wed Apr 30 00:13:03 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: Fwd: [Magic-dev] Magic: Licensing and embedding readline libraries In-Reply-To: <13dbfe4f0804271222m1cb70475gae227390c17f3102@mail.gmail.com> References: <20080427010725.W39713@shannon.csl.cornell.edu> <481498CA.9060105@opencircuitdesign.com> <13dbfe4f0804271222m1cb70475gae227390c17f3102@mail.gmail.com> Message-ID: [Below Mail was sent to me instead of the list by mistake I guess, as it addresses Tim] ---------- Forwarded message ---------- From: Chitlesh GOORAH Date: Mon, Apr 28, 2008 at 12:52 AM Subject: Re: [Magic-dev] Magic: Licensing and embedding readline libraries To: Aanjhan R On Sun, Apr 27, 2008 at 8:46 PM, R. Timothy Edwards > Any mention of GPL in the Fedora package must be in error. I have > never been able to tell exactly what license Magic falls under, but > I would assume it to be a BSD license. Hello Tim, I guess that this is an upstream issue, because when I was asked to prove the GPL license of Magic during the package review of Magic (for Fedora Project), I've pointed them to http://opencircuitdesign.com/ The very first paragraph states: "" Thank you for visiting the Open Circuit Design website. This website is the repository for the suite of open-source EDA (Electronic Design Automation) tools including Magic, IRSIM, Netgen, PCB, and XCircuit. These tools are all provided for free under the GNU Public License (GPL). "" Here the word _all_ had said everything. On Sun, Apr 27, 2008 at 6:51 PM, Aanjhan R < hidden > wrote: > The only way out is to hack in getting the package use > libreadline of the distro or some such. I'll advise you to opt for the system wide packages. Believe me for debugging or bugfixing, it will be very helpful. At the fedora project, every packager _should_ comply to use system wide packages only. > I am still wondering how Fedora resolved this license conflict. If the official website says GPL, it's GPL for me. However, if there is a mistake somewhere, that might be my fault, along with a lot of misunderstanding from all the parties. I'm eager to know what will be the license of all the tools from opencircuitdesign.com. Kind regards, Chitlesh PS: I'm on vacation as from this Wednesday for 2 weeks. I might not be able to change the licenses at the Fedora Project if needed, during that period. But certainly will when I'll be back. -- Aanjhan ------------ http://www.tuxmaniac.com From aanjhan at gmail.com Sun May 11 15:39:23 2008 From: aanjhan at gmail.com (Aanjhan R) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic: Licensing and embedding readline libraries In-Reply-To: <481498CA.9060105@opencircuitdesign.com> References: <20080427010725.W39713@shannon.csl.cornell.edu> <481498CA.9060105@opencircuitdesign.com> Message-ID: Dear Tim, On Sun, Apr 27, 2008 at 8:46 PM, R. Timothy Edwards wrote: > Any mention of GPL in the Fedora package must be in error. I have > never been able to tell exactly what license Magic falls under, but > I would assume it to be a BSD license. Can we have a COPYRIGHT file put up along with the source code when the next version of magic is released? Or atleast a confirmation from the devels that the license is "BSD Modified" which is compatible with GPL so that we have more wider user base and help those who are using Debian based distros to make full use of this wonderful Layout tool. Thanks and Regards, Aanjhan From IlanB at raysat.com Thu May 1 11:39:25 2008 From: IlanB at raysat.com (Ilan Barak) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic trouble on Suse10.3 64bit References: <4BD3F4EEA2F6E349A92780432B394D518934C6@exch-srv.raysat.co.il> Message-ID: <4BD3F4EEA2F6E349A92780432B394D51901894@exch-srv.raysat.co.il> OK, compiling rev 7.5.133 got it working. I still get the following: Configuration Summary (principle requirements): X11: yes OpenGL: yes Tcl/Tk: yes BLT: no Tcl/Tk magic uses the BLT package to create a tree diagram of the cell hierarchy in a design. Without it, this option is unavailable. Consider installing the BLT package. Please help Thanks Ilan ________________________________ From: magic-dev-bounces@csl.cornell.edu [mailto:magic-dev-bounces@csl.cornell.edu] On Behalf Of Ilan Barak Sent: Friday, April 25, 2008 11:29 AM To: magic-dev@vlsi.cornell.edu Subject: [Magic-dev] Magic trouble on Suse10.3 64bit I apologize for the long list, and hope it will help to explain may problem. An example of the corrupt magic screen can be seen at http://barak.hopto.org/ilan/temp/x1.jpg I am having trouble running (and configuring ) Magic on Suse 10.3 Linux x_64 (amd) I have tcl installed ilanlinux:/home/ilanb/downloads/magic # rpm -qa | grep tcl tcl-32bit-8.4.15-22 tclx-8.4-406 tcl-8.4.15-22 tcllib-1.9-53 tcl-devel-8.4.15-22 and Tk tk-devel-8.4.15-25.3 tk-8.4.15-25 and blt blt-2.4z-301 when I run ./configure I get checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ANSI C... none needed checking how to run the C preprocessor... gcc -E checking for library containing strerror... none required checking for a BSD-compatible install... /usr/bin/install -c checking for ranlib... ranlib checking for gm4... no checking for gnum4... no checking for m4... /usr/bin/m4 checking for ld used by GCC... /usr/x86_64-suse-linux/bin/ld checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes checking for egrep... grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for void *... yes checking size of void *... 8 checking for unsigned int... yes checking size of unsigned int... 4 checking for unsigned long... yes checking size of unsigned long... 8 checking for unsigned long long... yes checking size of unsigned long long... 8 checking whether byte ordering is bigendian... no checking for ANSI C header files... (cached) yes checking for setenv... yes checking for putenv... yes checking for vfork... yes checking sys/mman.h usability... yes checking sys/mman.h presence... yes checking for sys/mman.h... yes checking dirent.h usability... yes checking dirent.h presence... yes checking for dirent.h... yes checking limits.h usability... yes checking limits.h presence... yes checking for limits.h... yes checking param.h usability... no checking param.h presence... no checking for param.h... no checking paths.h usability... yes checking paths.h presence... yes checking for paths.h... yes checking for va_copy... yes checking for __va_copy... yes checking for gcore... no checking for csh... /usr/bin/csh checking for X... libraries /usr/lib64, headers checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for XOpenDevice in -lXi... yes checking for XmuInternAtom in -lXmu... yes checking for XextFindDisplay in -lXext... yes checking for tclConfig.sh... /usr/local/lib/tclConfig.sh checking for tkConfig.sh... /usr/local/lib/tkConfig.sh checking for wish executable... /usr/local/bin/wish8.4 checking for tclsh executable... /usr/local/bin/tclsh8.4 checking GL/gl.h usability... yes checking GL/gl.h presence... yes checking for GL/gl.h... yes checking for glXCreateContext in -lGL... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes configure: creating ./config.status config.status: creating defs.mak ----------------------------------------------------------- Configuration Summary (principle requirements): X11: yes OpenGL: yes Tcl/Tk: yes BLT: no Tcl/Tk magic uses the BLT package to create a tree diagram of the cell hierarchy in a design. Without it, this option is unavailable. Consider installing the BLT package. ----------------------------------------------------------- Use 'make' to compile and 'make install' to install. Errors may not be printed to stdout: see files 'make.log' and 'install.log' for complete error summary. ----------------------------------------------------------- I make and make install OK ilanb@ilanlinux:~/downloads/magic> make --- errors and warnings logged in file make.log --- making modules --- making Tcl shared libraries ilanb@ilanlinux:~/downloads/magic> su Password: ilanlinux:/home/ilanb/downloads/magic # make install --- installing executable to /usr/local/bin --- installing runtime files to /usr/local/lib ilanlinux:/home/ilanb/downloads/magic # but magic crashes due to wish8.5 in tkcon.tcl /usr/local/lib/magic/tcl/tkcon.tcl: line 3: /usr/local/bin/wish8.5: No such file or directory /usr/local/lib/magic/tcl/tkcon.tcl: line 3: exec: /usr/local/bin/wish8.5: cannot execute: No such file or directory When I correct the line in magic MAGIC_WISH=/usr/local/bin/wish8.5 to wish8.4 magic starts but the layout window is empty, no tools or menuse. The console shows: loading history file ... 0 events added error in slave eval: couldn't load file "/usr/local/lib/magic/tcl/tclmagic.so": /usr/local/lib/magic/tcl/tclmagic.so: undefined symbol: Tcl_PkgInitStubsCheck Main console display active (Tcl8.4.19 / Tk8.4.19) (magic-7.5.131) 1 % Can anyone help Ilan Barak -------------- next part -------------- An HTML attachment was scrubbed... URL: http://vlsi.csl.cornell.edu/pipermail/magic-dev/attachments/20080501/55f88208/attachment.html From adamore at email.it Wed Apr 30 21:07:15 2008 From: adamore at email.it (Andrea D'Amore) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Re: further problems building on OS X In-Reply-To: <481360BD.5070305@opencircuitdesign.com> References: <4AF88D72-BC92-431D-A88B-CCE7E5577CEA@email.it> <481218D4.3000506@multigig.com> <54D30FEB-442A-4AB2-B22B-FCA67DC2DC25@email.it> <481360BD.5070305@opencircuitdesign.com> Message-ID: <99696FCD-B398-44E6-BC1C-B8A9CF933657@email.it> On 26/apr/08, at 19:05, R. Timothy Edwards wrote: > This would *not* be the proper approach, I eventually found a way: build magic with tcl/tk support and install it, then perform a make clean, reconfigure --with-interpreter=no and build standalone ext2sim and ext2spice. Is there a way to turn off exttosim and exttospice tcl functions when building with tcl/tk ? From philippe at alpha.ece.jhu.edu Sat May 17 13:47:19 2008 From: philippe at alpha.ece.jhu.edu (Philippe Pouliquen) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic stacked contact bug... Message-ID: <20080517122503.R59784@alpha.ece.jhu.edu> Hi All, There seems to be a couple bugs in Magic's stacked contacts or possibly I'm writing my techfiles incorrectly. These two bugs seem to have been around for a while, and no one else seems to have reported any trouble, so I'm suspicious that that the latter may be the problem. On the other hand, I let my students have a go at 7.5.115, so possibly it's gotten a little more exposure than usual. Anyway, these two bugs are definitely in versions as early as 7.5.108, and also present in the current version 7.5.137. The first bug is that when you use stretch to move a contact at the end of a wire (by more than the contact size), the wire should shrink in length, but this only occurs for one of the contact's residue types. You can observe this problem in the attached layout with the long command: box 0 0 4 4 ; select area ; stretch u 10 The metal 1 will be shortened as normal, but the metal 2 does not. A temporary work-around is to move in steps of 4 or less -- but that brings us to the second bug. The second bug is more insidious. If you move a stack of three contacts more than once, the middle contact is dropped. This occurs if you move something diagonally, as the move has to be done with two separate "Manhattan" moves. (I don't know if stacks of four or more are affected as I haven't been working with a techfile that had that many stackable contacts lately.) You can duplicate this problem in the sample layout with the command: box 20 0 24 4 ; select area ; move r 10 ; move u 10 You can see that the middle contact has been dropped from the selection by inserting a "what" command around the moves. Note that on the second move, you will get a warning about "You selected paint outside the edit cell..." This warning might be generated anyway if your original selection contained paint in a subcell, so who pays attention :-) A temporary work-around is to modify the command to be: box 20 0 24 4 ; select area ; move r 10 ; select area ; move u 10 but it's not that useful for complicated selection patterns. For those, you just need to do a "move to ...". Philippe Pouliquen The Johns Hopkins University -------------- next part -------------- magic tech simple timestamp 1211041433 << metal1 >> rect 0 4 4 28 rect 10 0 14 4 << metal2 >> rect 0 4 4 28 rect 10 8 14 12 << metal3 >> rect 10 16 14 20 << metal4 >> rect 10 24 14 28 << m12contact >> rect 0 0 4 4 rect 10 4 14 8 rect 20 0 24 4 << m23contact >> rect 10 12 14 16 rect 20 0 24 4 << m34contact >> rect 10 20 14 24 rect 20 0 24 4 << end >> -------------- next part -------------- tech format 33 simple end version version 1 description "Magic debug" end planes metal1,m1 metal2,m2 metal3,m3 metal4,m4 end types metal1 metal1,m1 metal2 metal2,m2 metal3 metal3,m3 metal4 metal4,m4 metal1 m12contact,m12c metal2 m23contact,m23c metal3 m34contact,m34c end contact m12c m1 m2 m23c m2 m3 m34c m3 m4 stackable end styles styletype mos m1 20 m2 21 m3 22 m4 23 m12c 20 m12c 21 m12c 33 m23c 21 m23c 22 m23c 37 m34c 22 m34c 23 m34c 38 error_p 42 error_s 42 error_ps 42 end compose end connect m1,m12c/m1 m1,m12c/m1 m2,m12c/m2,m23c/m2 m2,m12c/m2,m23c/m2 m3,m23c/m3,m34c/m3 m3,m23c/m3,m34c/m3 m4,m34c/m4 m4,m34c/m4 end cifoutput end cifinput end # mzrouter # end drc end extract style debug planeorder metal1 0 planeorder metal2 1 planeorder metal3 2 planeorder metal4 3 end # wiring # end # router # end # plowing # end # plot # end From tim at opencircuitdesign.com Sat May 17 14:06:01 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic stacked contact bug... In-Reply-To: <20080517122503.R59784@alpha.ece.jhu.edu> References: <20080517122503.R59784@alpha.ece.jhu.edu> Message-ID: <482F3AA9.6080406@opencircuitdesign.com> Dear Philippe, > The second bug is more insidious. If you move a stack of three contacts > more than once, the middle contact is dropped. This occurs if you move > something diagonally, as the move has to be done with two separate > "Manhattan" moves. (I don't know if stacks of four or more are affected > as I haven't been working with a techfile that had that many stackable > contacts lately.) Not to sound like I'm trying to make excuses for the bug (which I intend to track down and fix), but you *can* do, e.g., "move nw 10" to perform a diagonal move in one step. ---Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From philippe at alpha.ece.jhu.edu Sat May 17 17:20:53 2008 From: philippe at alpha.ece.jhu.edu (Philippe Pouliquen) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic stacked contact bug... In-Reply-To: <482F3AA9.6080406@opencircuitdesign.com> References: <20080517122503.R59784@alpha.ece.jhu.edu> <482F3AA9.6080406@opencircuitdesign.com> Message-ID: <20080517161106.R59784@alpha.ece.jhu.edu> Hi Tim, > Not to sound like I'm trying to make excuses for the bug (which I intend > to track down and fix), but you *can* do, e.g., "move nw 10" to perform > a diagonal move in one step. Nice. New feature eh? But uh, not generally useful (45 degrees only). Something along the lines of "move n 10 e 10" or "move ne 10 10" would be better. In fact I think I like the latter best, because then "move ne 10" would be a more natural short version. Should be trivial to implement... By the way, how come "move ne 10 10" currently only move diagonally by 1? Philippe Pouliquen The Johns Hopkins University From tim at opencircuitdesign.com Sat May 17 15:23:03 2008 From: tim at opencircuitdesign.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Magic stacked contact bug... In-Reply-To: <20080517161106.R59784@alpha.ece.jhu.edu> References: <20080517122503.R59784@alpha.ece.jhu.edu> <482F3AA9.6080406@opencircuitdesign.com> <20080517161106.R59784@alpha.ece.jhu.edu> Message-ID: <482F4CB7.8060009@opencircuitdesign.com> Dear Philippe, > Nice. New feature eh? But uh, not generally useful (45 degrees only). The feature has been there for several years. . . I guess I probably need to figure out some way to notify people of useful changes other than requiring them to read the "code changes" list! > Something along the lines of "move n 10 e 10" or "move ne 10 10" would > be better. In fact I think I like the latter best, because then "move > ne 10" would be a more natural short version. Should be trivial to > implement... Yes, it's trivial to implement (I just did it). However, I noticed that "move ne 10 10" is redundant, as "move 10 10" suffices, so I made the additional change of allowing the direction to be unspecified if both X and Y coordinates are given. So the syntax for "move" and "move to" is now equivalent when a direction is not given, with "move" being relative and "move to" being absolute (and, of course, equivalent changes made to the "copy" command; "stretch" would be very difficult to make non-Manhattan). > By the way, how come "move ne 10 10" currently only move diagonally by 1? Lack of error message printing, since magic didn't understand "10 10" as a distance value, and so defaulted to 1. The error still exists, since with the new changes, "move 10" likewise can't parse the entry and so defaults to distance 1 and direction NE. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-9364 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From tim.edwards at multigig.com Sun May 25 23:16:39 2008 From: tim.edwards at multigig.com (R. Timothy Edwards) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Re: Magic Troubles In-Reply-To: <707ac7370805252141y39bc923btfddc0646f18d7c12@mail.gmail.com> References: <707ac7370805252141y39bc923btfddc0646f18d7c12@mail.gmail.com> Message-ID: <483A47B7.90904@multigig.com> Dear Gagi, > I just installed the latest stable release 7.5.140 of magic, and for > some reason none of the standard shortcuts work anymore. > > For example when I attempt to turn on the grid with the by pressing > 'g' the following error is displayed. > > Unknown macro or short command: 'Meta_XK_g' Philippe Pouliquen sent me a patch that was supposed to fix the handling of the "Alt" key on Mac OS-X. Apparently that breaks something on your setup. According to one of your earlier emails (October), you were working on an Ubuntu system. Is that still the case? It appears that you have something like NumLock or other random key set "on" and mapped to one of the key modifier masks "Mod2Mask" through "Mod5Mask". Previously, Magic only looked at Mod1Mask and assumed this was the "Alt" key. However, Mac OS-X maps Mod2Mask to the "Alt" key, so the code was changed to map *all* of the extra modifier masks to Mod1Mask, on the assumption that the "Alt" key would get mapped one way or another. That appears to be an over-reaching assumption. If, for example, your system maps NumLock to Mod3Mask, and NumLock is on, then the new code will make Magic believe that you have the "Alt" (otherwise called "Meta", as it reported to you) held down all the time. Obviously you don't want this. So, (1) if you have some kind of keyboard scanning program (there's one you can probably still get called "xkeycaps"), then maybe you can find out which of the modifier masks is on, and why. (2) You can also do this by trial-and-error by removing, one at a time, each of Mod5Mask through Mod2Mask in graphics/grTk1.c, line 809, recompiling, and determining which one is semi-permanently active. Also, (3) you can try turning on and off various "special" keys like NumLock, ScrollLock, to figure out if they are mapped to one of the modifier masks. > Also I have never been able to start the 3D view, I always get the > following error: > > invalid command name ".render.magic" You will need to start Magic with "magic -d OGL" to get the 3D rendering capability. I hadn't realized that the "3D window" option remains in the window when the OpenGL interface is unavailable; it should be disabled or removed. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim.edwards@multigig.com | | MultiGiG, Inc. | web: http://www.multigig.com | | 100 Enterprise Way, Suite A-3 | phone: (831) 621-3283 | | Scotts Valley, CA 95066 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From philippe at alpha.ece.jhu.edu Tue May 27 12:34:40 2008 From: philippe at alpha.ece.jhu.edu (Philippe Pouliquen) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] Re: Magic Troubles In-Reply-To: <483A47B7.90904@multigig.com> References: <707ac7370805252141y39bc923btfddc0646f18d7c12@mail.gmail.com> <483A47B7.90904@multigig.com> Message-ID: <20080527112309.Q99722@alpha.ece.jhu.edu> Hi Tim, Gagi, Yes, NumLock (which I don't ever use, or I would have seen this when I suggested the patch) is also Mod2Mask on Linux/FreeBSD. Hence, there is no way to make vanilla Xorg/Xfree86 systems and MacOSX systems compatible. It looks like we will need to revert to the old code and add an #ifdef to handle the Mac OS X. Alternatively, there may be a way to handle this in "configure" by synthesizing a key press. I've never tried this myself, but I seem to recall that X windows allows you to fake user interaction with a window. Of course, this can only work if X windows is running at the time configure is run. > So, (1) if you have some kind of keyboard scanning program (there's one > you can probably still get called "xkeycaps"), then maybe you can find > out which of the modifier masks is on, and why. All vanilla X windows installations should come with "xev", so you can try that if nothing simpler is available. Look for the "state" variable. (The mapping of state to modifier is defined in X.h.) Philippe From fang at csl.cornell.edu Mon Oct 27 14:14:42 2008 From: fang at csl.cornell.edu (David Fang) Date: Thu Oct 30 14:34:12 2008 Subject: [Magic-dev] testing, please ignore Message-ID: <20081027131320.G13441@shannon.csl.cornell.edu> Nothing to see here, this is just a test message for this mailing list. your friendly list admin, Fang David Fang Computer Systems Laboratory Electrical & Computer Engineering Cornell University http://www.csl.cornell.edu/~fang/ -- (2400 baud? Netscape 3.0?? lynx??? No problem!) From tim.edwards at multigig.com Mon Nov 3 09:07:32 2008 From: tim.edwards at multigig.com (R. Timothy Edwards) Date: Mon Nov 3 09:07:59 2008 Subject: [Magic-dev] Re: Magic 7.5 In-Reply-To: <848293.90721.qm@web59615.mail.ac4.yahoo.com> References: <848293.90721.qm@web59615.mail.ac4.yahoo.com> Message-ID: <490F05A4.1080907@multigig.com> Dear Salim, > I am sending this email to > ask about a potential bug in Magic 7.5. I posted about the problem in > Cornell mailing list but got no response. I installed Magic 7.5 and > noticed the plow command doesn't work properly. Most of the time it > merely erases what's under the box. I removed it and installed the 7.4 > version, and the command worked correctly. Has anyone noticed this > problem before? Is this a bug in the release or could it be just on my > computer? Yes, unfortunately, I made some changes to the DRC rules database that also happens to be used by the plow command. So the plow command is "temporarily" broken, although I admit to having taken a rather long time without getting around to fixing it. From the "code changes" page on the website: July 29, 2006 at 2:40am 2006-07-28 08:57 tim Major, major changes to the router code in Magic. Reorganized the initialization routines for the routers so that they are stable with respect to reloading technology files and rescaling magic's internal grid. Fixed the code that is exercised by the "tech drc ..." command, and used this code to set the maze router properties. Added a "tech drc surround" command option and associated code, which is currently not yet attached to the maze router initialization (but will be done soon). One side effect: The "plow" rule setup has been removed, so the "plow" function is temporarily disabled, until I can put them back in, based on the "tech drc" code. As you can see, "temporarily" means over two years. . . really, I don't use plowing myself, and so I have been waiting for someone to complain about the lack of plowing functionality in version 7.5. So I'll move it up on my priority list. Regards, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim.edwards@multigig.com | | MultiGiG, Inc. | web: http://www.multigig.com | | 100 Enterprise Way, Suite A-3 | phone: (831) 621-3283 | | Scotts Valley, CA 95066 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+ From tim at opencircuitdesign.com Tue Nov 25 20:23:44 2008 From: tim at opencircuitdesign.com (Tim Edwards) Date: Tue Nov 25 20:24:05 2008 Subject: [Magic-dev] New contact cut algorithm for magic Message-ID: <492CA520.4050505@opencircuitdesign.com> All of you users of Magic who have put up for years with Magic's implementation of contact cuts will be pleased to know that I've spent the last week or so implementing an entirely new contact cut generation algorithm, which will be introduced in version 7.5.159. The old algorithm was tile-based, and required contacts to be isolated rectangles. The new algorithm operates on contact areas of arbitrary shapes, and can place contact cuts properly into everything from octagonal pads to intersecting guard rings. I think everyone will find this to be a great enhancement to the program. I could use some beta testers to give the algorithm a good torture test. Thanks, Tim +--------------------------------+-------------------------------------+ | Dr. R. Timothy Edwards (Tim) | email: tim@opencircuitdesign.com | | Open Circuit Design, Inc. | web: http://opencircuitdesign.com | | 22815 Timber Creek Lane | phone: (301) 528-5030 | | Clarksburg, MD 20871-4001 | cell: (240) 401-0616 | +--------------------------------+-------------------------------------+