gEDA-user: How to make gnetlist output properly in case of vectored inputs and outputs.
Hello, Some XSPICE models have vector inputs and vector outputs. In such cases, how to make gnetlist generate the correct netlist by putting the node numbers or names within square brackets like this: [1 2 ] Thanks for your help. Anand -- Close Windows ! Open source !! Free software from proprietary mafia !!! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: How to make gnetlist output properly in case of XSPICE models requiring vector inputs and vector outputs?
Hello, Some XSPICE models have vector inputs and vector outputs. In such cases, how to make gnetlist generate the correct netlist by putting the node numbers or names within square brackets like this: [1 2 ] Thanks for your help. Anand -- Close Windows ! Open source !! Free software from proprietary mafia !!! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to submit symbols to be included in the official distribution of gEDA Suite?
Dear Kai-Martin, Thanks for your information. I will contact DJ. Sincerely, RSA On Tue, Jul 12, 2011 at 5:06 AM, Kai-Martin Knaak [1]k...@familieknaak.de wrote: Ananda Murthy R S wrote: I have noticed that XSPICE code models do not have corresponding symbols. I have prepared symbols for these code models. How to submit them to be included in the official distribution of gEDA Suite? The default lib is currently not maintained. Additions have not been accepted for at least five years. Instead, there is a site dedicated to contributions: [2]http://www.gedasymbols.org I'd recommend, you get a personal section there and upload your symbols there. Send an email to [3]dj-at-delorie.com and DJ will gladly provide you with a CVS access. ---)kaimartin(--- -- Kai-Martin Knaak Email: [4]k...@familieknaak.de [5]http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 not happy with moderation of geda-user ___ geda-user mailing list [6]geda-user@moria.seul.org [7]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Close Windows ! Open source !! Free software from proprietary mafia !!! References 1. mailto:k...@familieknaak.de 2. http://www.gedasymbols.org/ 3. http://dj-at-delorie.com/ 4. mailto:k...@familieknaak.de 5. http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 6. mailto:geda-user@moria.seul.org 7. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gschem gnetlist problem
Hello all, I am trying to use gnetlist for the first time to create a Bill Of Materials (BOM) from my schematic. This is a test case of mine to come up with a procedure to do this. I keep getting the following: 536:$gnetlist -g bom xx.sch Loading schematic [/home/gherr/projects/vds160/original/hardware/dac/docs/xx.sch] Backtrace: In current input: 1: 0* [bom output.net] In /usr/local/share/gEDA/scheme/gnet-bom.scm: 37: 1 (let ((port #) (attriblist #)) (bom:printlist (cons # attriblist) port) ...) 40: 2* [bom:parseconfig ... 40: 3* [open-input-file attribs] In unknown file: ?: 4 [open-file attribs r] unnamed port: In procedure open-file in expression (open-file str OPEN_READ): unnamed port: No such file or directory: attribs It produces essentially the same error when using bom2. Of course, the output.net file is empty. What is this attribs file it seems to be looking for and not finding? Am I supposed to create this file? If so, where can I find a description of it? I have looked at the manpage, the gnetlist User's Guide, did some searching on the web for this error (gnetlist [open-file attribs r] ), and looked at the distribution for more documentation, all to no avail. For the record, I am using gEDA 1.6.2.20110115, KDE 3.5.10, Slackware Linux 12.2 (k2.6.27.7). I am not a schema/guile/lisp programmer, but I do program in other languages. I would appreciate any hints to get me back on track with gnetlist. Thanks in advance. Girvin Herr ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem gnetlist problem
DJ Delorie wrote: What is this attribs file it seems to be looking for and not finding? Am I supposed to create this file? If so, where can I find a description of it? It's a list of attributes for which you want extracts. http://geda.seul.org/wiki/geda:bom_readme DJ, Thanks! That got it going. I thought it was something like that, but wasn't sure. Onward and upward! Girvin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: How to submit symbols to be included in the official distribution of gEDA Suite?
Hello, I have noticed that XSPICE code models do not have corresponding symbols. I have prepared symbols for these code models. How to submit them to be included in the official distribution of gEDA Suite? Anand -- Close Windows ! Open source !! Free software from proprietary mafia !!! ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gschem unresponsive to keyboard input
Kai-Martin Knaak wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. One of the electronics newbies I teach geda, hit a strange input mode in gschem today. The GUI did not respond to the usual key-accels (ee, m, i...). Instead, on the bottom right of the window the status line displayed the letters just typed in upper case. [return] , [escape] or any combinations we came up with did not end the mode. In the end, we restarted the session to bring back the expected behavior. What is this mode supposed to do? How would it be entered? How can it be ended? Can I assume you tried Caps Lock? I am always forgetting to remove Caps Lock and gschem exhibits the behavior you describe. The commands are case sensitive. HTH. Girvin Herr - ---)kaimartin(--- - -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkx8FDkACgkQZ+Hj7ZLnhr9LmACeMqkB6Onmq0gektzQNaZMZAau aHQAnAgJnaG5KOvpEvqdIFDocnIJlPW+ =YcqZ -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Refreshing symbol libraries ?
Amond, I had this problem too, until I found the refresh icon: Add - component In the Select Component... window, click on the circular arrows icon to the right of the Filter box. That should refresh the listing without restarting gschem. Still using gschem 1.4.0.20080127. I sure hope they didn't drop that feature in the later versions... Girvin Herr Amand Tihon wrote: Hi, Is there a way to have gschem rescan its component libraries while running ? Currently, when I copy or create a new symbol into the project directory, I have to restart gschem to make it visible in the component browser. Thanks. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: On integrating simulator in gschem
On Tue, Mar 16, 2010 at 11:58 AM, kai-martin knaak grace has them all and more. It doesn't support waveform formats produced by popular analog and digital simulators. It doesn't make it easy to browse a (sometimes very large) signal database, select signals and quickly apply some common EE-specific operations on them. Finally, it wasn't optimized for processing 2 weeks' worth of simulation results efficiently. Those are features that some of good waveform viewers have. Unfortunately none of them is open source and such tool would indeed be very useful, regardless of what the rest of the design flow looks like. Grace and gnuplot are good tools in their own domains. And yes, they are useful for an EE too (e.g. for preparing publication quality plots). IMHO, you underestimate the effort to get were grace and gnuplot already are. I had a look at oscope and it seams fairly well designed. Authors have done a pretty good job so far so I wouldn't be worried about their qualifications. I would certainly not discourage them from further work on their tool. -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Open Source mechanical CAD on the horizon
Kai-Martin Knaak wrote: I just got aware of the open source mechanical CAD project freecad. It hit the debian repository a month ago. Although it is still lacking important features, much of the basic infrastructure is already up and running. http://en.wikipedia.org/wiki/FreeCAD_(Juergen_Riegel) ---(kaimartin) Kai, Have you, or anyone in the group, used FreeCAD for any useful work? I just downloaded the source code for Linux and took a look at the docs. Although they may not be up to date (file date of Jan 7, 2010), they have no substance. It is proclaiming there isn't yet much in the way of GUI commands to implement the internal drawing functions. I am looking for a free and Open Source mechanical drawing program to complement gEDA. i.e.: Okay, we have the PWB out for fab, now let's design and document an enclosure! I have been using gschem's drawing capability for much of my projects' mechanical documentation. For the most part, it is acceptable for that, however, gschem has a few limitations, such as lack of drawing ellipses for oval speaker cutouts, that real mechanical drawing programs support. FreeCAD looks promising on the surface; however, before I install and/or update a lot of Linux system support libraries for FreeCAD, I would like to hear from someone who actually found FreeCAD useful at this stage of its development (version 0.9.2646). TIA. Girvin Herr ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ubuntu package for 1.6 and footprints
Kelvin Gardiner wrote: I use Ubuntu which has gschem 1.4. So I've downloaded the newest code with git and compiled it. Given that there seems to be quite few changes is there any plans to build a 1.6 Ubuntu package either for relase in the Ubuntu repos or via a PPA. Hi Kevin, Please see this bug: https://bugs.launchpad.net/ubuntu/+source/geda-gattrib/+bug/444527 Maybe you could help them? Since I'm done with compiling atm, I'll wait ;-) Big thanks from my part ;-) Remy ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ubuntu package for 1.6 and footprints
John P. Doty wrote: R. Bosch wrote: B.t.w.: Just noticed that it's almost a year since 20081128 was released. Any idea why it never came in Ubuntu? Which is still at 20080202... :-/ Hmm, Ubuntu Jaunty is at: gEDA/gschem version 1.4.3.20081231 Be nice if 1.6 was there, but it's not as bad as you say. Forgot to mention PCB Sorry for the ommision :-) Remy ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gsch2pcb shorting circuits in netfile
Hi all, I make a schematic, find no fault in the DRC (gnetlist -g drc2 powerbox.sch). I generated the pcb files with gsch2pcb Projectfile I open the generated powerbox_pcb.net and spread out the footprints. I import the netlist and see GND has been created even though it doesn't exist in the schematic. I noticed it on conn2 from which conn2-1 and conn2-2 are both connected and the same goes for C5. Reference files: Schematic: http://pastebin.ca/1627825 Netlist: http://pastebin.ca/1627833 LT1086-4: http://pastebin.ca/1627852 What am I doing wrong here? I all ready tried supplying netnames, and re-creating the complete schematic from scratch (which is supplied). [Projectfile] schematics powerbox.sch output-name powerbox_pcb elements-dir /home/remy/Projects/Bike elektronics/library/pcb/vreg elements-dir /home/remy/Projects/Bike elektronics/library/pcb/Diode elements-dir /home/remy/Projects/Bike elektronics/library/pcb/Potmeters elements-dir /home/remy/Projects/Bike elektronics/library/pcb/Connectors [/Projectfile] Note: Tried with skip-m4 which made no difference. gsch2pcb gave me the following output: [output] $ gsch2pcb Projectfile - gEDA/gnetlist pcbpins Backend This backend is EXPERIMENTAL Use at your own risk! - Using the m4 processor for pcb footprints -- Done processing. Work performed: 16 file elements and 21 m4 elements added to powerbox_pcb.pcb. Next step: 1. Run pcb on your file powerbox_pcb.pcb. You will find all your footprints in a bundle ready for you to place or disperse with Select - Disperse all elements in PCB. 2. From within PCB, select File - Load netlist file and select powerbox_pcb.net to load the netlist. 3. From within PCB, enter :ExecuteFile(powerbox_pcb.cmd) to propagate the pin names of all footprints to the layout. [/output] Thanks in advance. Greetings, Remy ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gsch2pcb shorting circuits in netfile
Stefan Salewski wrote: T 1600 900 8 10 0 0 0 0 1 net=GND:2 T 1600 1470 8 10 0 0 0 0 1 Oh, that's a classic... :turning-red: Tested and it works better now. I use the stable 1.4.3 On Xubuntu 9.04. The 1.5.3/4 isn't available yet... Thanks and I apologize... ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: ngspice transfer function
Hi, There is no DC path from node '1' to the ground (node '0'). Add a large resistor between them and the simulation will work: Tranfer function ISRC 1 0 AC 1 R1 1 2 1k C1 2 3 1u R2 3 0 1k C2 3 0 1u R10 1 0 1e+12 .AC DEC 10 1 10K .END Actually, Ngspice tried to fix it by inserting GMIN to the circuit (a small conductance between each node and the ground) but for some reason it didn't work. Does anyone knows why? Cheers, -r On Sun, Aug 23, 2009 at 10:23 PM, cedriccedric_li...@bbox.fr wrote: Hi, I am a ngspice newbie and I'd like to get a frequential transfer function of a Wien filter as an exercise . I'd like to plot V(3)/ISRC versus frequency . Here is the .sch file I simulate : Tranfer function ISRC 1 0 AC 1 R1 1 2 1k C1 2 3 1u R2 3 0 1k C2 3 0 1u .AC DEC 10 1 10K .END Here is the result I get : ngspice 1 - run Doing analysis at TEMP = 27.00 and TNOM = 27.00 Warning: Source isrc has no value, DC 0 assumed Warning: singular matrix: check nodes 1 and 1 Note: starting dynamic Gmin stepping Trying gmin = 1.E-03 Note: One successful Gmin step Trying gmin = 1.E-04 Note: One successful Gmin step Trying gmin = 1.E-05 Note: One successful Gmin step Trying gmin = 1.E-06 Note: One successful Gmin step Trying gmin = 1.E-07 Note: One successful Gmin step Trying gmin = 1.E-08 Note: One successful Gmin step Trying gmin = 1.E-09 Note: One successful Gmin step Trying gmin = 1.E-10 Note: One successful Gmin step Trying gmin = 1.E-11 Note: One successful Gmin step Trying gmin = 1.E-12 Note: One successful Gmin step Trying gmin = 1.E-12 Note: One successful Gmin step Warning: singular matrix: check nodes 1 and 1 Warning: Dynamic Gmin stepping failed Note: starting source stepping Supplies reduced to 0.% Warning: singular matrix: check nodes 1 and 1 Trying gmin = 1.E-02 Note: One successful Gmin step Trying gmin = 1.E-03 Note: One successful Gmin step Trying gmin = 1.E-04 Note: One successful Gmin step Trying gmin = 1.E-05 Note: One successful Gmin step Trying gmin = 1.E-06 Note: One successful Gmin step Trying gmin = 1.E-07 Note: One successful Gmin step Trying gmin = 1.E-08 Note: One successful Gmin step Trying gmin = 1.E-09 Note: One successful Gmin step Trying gmin = 1.E-10 Note: One successful Gmin step Trying gmin = 1.E-11 Note: One successful Gmin step Trying gmin = 1.E-12 Note: One successful Gmin step Note: One successful source step Supplies reduced to 0.1000% Warning: singular matrix: check nodes 1 and 1 Supplies reduced to 0.% Warning: singular matrix: check nodes 1 and 1 Warning: source stepping failed AC operating point failed - Last Node Voltages -- Node Last Voltage Previous Iter - 1 0 0 2 0 0 3 0 0 doAnalyses: iteration limit reached run simulation(s) aborted Does someone has an idea about what's wrong in the scheme file ? Thanks for your help, ced ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, Aug 15, 2009 at 5:12 AM, al davisad...@freeelectron.net wrote: A netlister needs to work for all symbols. No exceptions. Why? Should it work even for symbols without models or incompatible models (e.g. verilog RTL in an analog AC simulation)? For Spice format, you can go nuts with all of the special cases. There are ways to control it, but you can't fix it completely. This means the netlister cannot have explicit knowledge of any particular symbol. Well, currently it has. I would actually prefer it the other way around, so that some particular symbols (especially primitive devices) had explicit knowledge of a netlist format. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Fri, Jul 31, 2009 at 8:49 PM, A.Burinskiyalexb...@gmail.com wrote: Dear gEDA community members, I created yet another netlister for gschem. Netlister supports flattened or hierarchical netlist, handles slotting and global net names. Will be glad to hear any feedback. The source located in: http://sourceforge.net/projects/ynetlist/files/ I will have a closer look at it later. Thanks. I'm a bit puzzled that all of you tend to choose C/C++ for implementing your tools. Netlisters are expected to be extendable by their end users but such a low level implementation language together with a build environment is a significant obstacle to it. It is not a theoretical dispute - I've been trying to extend Anthony's spnet and I soon got tired of doing text processing in C. Please treat this as my private suggestion only: would you or Anthony consider rewriting your tool in Perl, Python or some other major scripting language? So far only gnetlist tries to employ some higher level language (guile) for processing the netlist but it suffers form other problems (guile itself is not very mature and gnetlist architecture is hardcoded in C, which is why it is so hard to add the hierarchy support to it). Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, Aug 1, 2009 at 2:49 PM, A.Burinskiyalexb...@gmail.com wrote: I thought about implementing some language for netlist and after all I decided to go with plain C++ and get rid of using device attribute unless it is absolutely necessary (such as input/output pin) and give more strength to user symbol definition relying on the fact that end user knows what [s]he does. After all, each symbol translated into very fixed semantic (Refdes node1 node2 name attributes ...). I don't think this is necessary. Sure, some tools (e.g. from Cadence) provide a simple embedded language that can be used by a designer to interact with the netlister (typed attributes, pPar(), iPar(), arithmetic functions etc.) but that's not what I meant (although it would be nice to have). Major problem - if syntax of gschem files will be changed, then gschem may loose compatibility with all previously collected works! Thus, if gschem will change format of output files it will change it in compatible way or being more strict - only on incremental way. In this case it would not be hard to make incremental adds to the code, if algorithm itself is flexible and transparent enough (C++, pcb/spice output formats, flattening/hierarchical some keys in config file). If you think of adding more flexibility I will be more than glad to change the code. I'm not sure if I understand you correctly. Yes, accessing the data files directly is a bit dangerous from API stability point of view. Ideally, libgeda would provide anyone interested with a set of functions for accessing the design and traversing the hierarchy. The benefit of this would be: 1. API abstraction, 2. The same logic and configuration would be used by gEDA tools. Speaking more about netlisters. Scriptising netlister - adding language inside language (you translate from .sch lang. to .net lang. using script) will force netlister to be more hardcoded (that is what happened with gnetlist, is not it?) instead of expectations to make more flexible semantic. And, finally, me, as a user, will not be happy to change the script each time I add new symbol! No, that's not what I meant. I just suggested that the whole netlister, as it is now, could be ported to an interpreted language, so that it was easier to understand and modify for a person who didn't write it. The extendability would be useful (although not required) for writing a library of complex components. Think about checking certain attributes if they hold legal values for a given process, precalculating MOS ad,as,pd,ps parameters, modifying netlist for monte-carlo simulations. You can consider these very heavy components designed for a given technology. In one word - I made my life easier choosing C++ without Perl or whatever. I think that definite advantage of using script will have tool that involves highly interactive tasks, for example analyzing result of simulation using waveform viewer, layout creation tool, PR Even for schematic entry - I doubt that scriptising schematic capture tool will help! Scripting is one thing, writing the tool in a scripting language is another. If performance is not a concern I would prefer to have a tool written in a scripting language so that I can change/extend it easily. This is what opensource is about after all. It doesn't mean that people can't do this with a tool written in C++ but the amount of work involved is far greater (downloading the source code, compilers, library headers, using the tool chain etc.) especially for people who are not programmers in their day jobs. Thanks again for writing the tool! Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, Aug 1, 2009 at 2:37 PM, John Dotyj...@noqsi.com wrote: Hmm, I think Guile is fine for gnetlist's purposes. A minor problem has been backward compatibility, leading to dependency hell. The people who package the distros have this under better control than they did a few years ago. Python has similar problems. I'm actually a big fan of functional languages so you don't need to convince _me_ to Scheme. ;-) The real problem, I think, is that many people get phobic when they see all those parentheses. But, really, Guile is easy to learn and easy to use. Well, I see several other problems here as well: 1. Guile (as a Scheme implementation) is not particularly well supported, this leads to dependency hell and missing/incomplete wrappers for modern libraries (like gtk2 - not really a problem for gnetlist but an issue for gschem and others), 2. Scheme being a simplistic language. Both Perl and Python come with regexps and easy to use and versatile container types to name a couple of useful features. 3. Scheme not being a main stream language (often misinterpreted as a parentheses problem). This makes code written in Scheme not easier to extend than one written in a primitive but well known language. So, from pragmatic POV, I am OK with moving from Guile to something more practical. and gnetlist architecture is hardcoded in C, Yes. Too much is hardcoded into the front end. The front end even gets in the way of the back end's access to command line options. Back ends can't see hierarchy. Back ends can't see all attributes. Now, a lot of back ends don't need to see all that stuff, but that's what the interface layer (gnetlist[-post].scm) is for: simple back ends can get the filtered info, trickier ones can reach around to the front end and get the data they need. The current implementation doesn't exploit the capabilities of the interface layer very well. The front end needs to be trimmed back to the minimum, and the logic moved to the interface layer. Hmm. In the gnetlist case, the minimum for the hard-coded part is nothing: why bother with C at all? Fully agree. The only exception is that part of functionality (reading and interpreting gEDA file formats) could be abstracted out in a form of libgeda library (still the netlister doesn't need to be written in C/C++, just libgeda itself). Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Yet another netlister
On Sat, Aug 1, 2009 at 5:09 PM, John Dotyj...@noqsi.com wrote: Perhaps not Guile, but we're going to have to keep Scheme around for a long time, because all those back ends are important. It's not that there's a lot of code in them, but they embody a great deal of research into just what each format needs (often the product of reverse engineering). Fair enough. What Scheme implementation will be used? And in the particular case of spice-sdb, Stuart has produced really good documentation. Those who want to improve SPICE netlisting would be well advised to read and understand that first. Thanks for your gnetlist tutorial, BTW. It was an interesting read. Improving backends is easy (well, relatively easy). What's hard is fixing the front-end so that it provides full design information to back-ends (including hierarchy and parameters, of course). I also think that the best way to do it is to implement this functionality in Scheme (so that all front-end data structures are naturally available to back-ends) but it is still OK to have this functionality in a compiled core provided it doesn't hide design information from its back-ends. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: merge multi symbol components
On Fri, Jul 24, 2009 at 3:06 PM, DJ Deloried...@delorie.com wrote: Well, you have to *use* its scriptability, and not fight against it. I don't consider it scriptable unless you can invoke the script from within the tool and have it operate on the live data. You should be able to, for example, right-click on a menu button and edit the script it will run, then left-click on it to run it. I don't really care whether scripting functionality is built in the tool or is not, as long as it seamlessly integrates with it. When the script modifies a design file the tool should update any views of it (I guess that's what you meant by operate on the live data). Another issue is what we consider scripting. For me, scripting is only good for automating the flow, glueing existing functions together so that the user's productivity increases. This is in opposition to plumbing, adding features to the tool, which should be there in first place, because it decreases productivity. A specialized internal language is a poor way to get scriptability. I don't consider pcb's actions scripts, more of a batch file. However, you have to *start* with a solid collection of verbs and nouns before you can build a scripting system around it. On the gschem side I really like the idea of libgeda. IMHO everything that touches user's data should go there and be wrapped with a clean API. Tools like gschem, netlisters, importers etc should only issue commands/listen to libgeda. Cheers, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Running a mixed analog and digital simulation possible?
Hi, There is also an experimental ADMS add-in for ngspice. Not sure whether it is usable now, though. Cheers, -r. On Thu, Jul 23, 2009 at 9:44 AM, Svenn Are Bjerkemsvenn.bjer...@googlemail.com wrote: Hi, I have been searching a bit on the net to try to find out if it is possible to run a mixed-signal simulation with open-source tools. So far I have mostly been using digital VHDL only and I find that the VHDL path is not there yet. Icarus seems to have some Verilog-AMS in place, and it seems like gnucap is used as the back end. Anybody has a pointer to a HOWTO for VAMS with icarus and gnucap? A different thing is the mixed-signal simulation. So far the commercial tools I have used use some kind of interface blocks between analog domain and digital domain and run an analog and a digital simulator in parallel to speed up the digital part. Is something like this available in the open-source domain? Nanosim seems to have a different approach: The accuracy is adjusted down for digital parts to lower the computing while keeping analog parts decent and both run in the same simulator. I only have access to commercial grade digital simulators, but would like to widen my horizon into mixed-signal. -- Svenn ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: spNet v0.9.2 released
On Wed, Jul 1, 2009 at 2:58 AM, Dan McMahilld...@mcmahill.net wrote: how does spNet compare to gnetman which is also an alternative hierarchical spice netlister for gschem? Sorry for silly question, where can I download it? -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: spNet v0.9.2 released
On Wed, Jul 1, 2009 at 2:30 AM, Anthony Shanksyamazak...@gmail.com wrote: Yes I know exactly what you mean now and I have seen (and have used) that kind of hierarchy control present in very high end tools (like cadence) Sorry, I should have guessed you don't need this kind of explanation. Looks like we are coming from similar background. but it is usually at the schematic capture level like you stated rather at the netlister level. gschem would have to drastically change to support that level of hierarchical maniuplation. That would be great but I wouldn't expect such change to occur any time soon. Even if we prepared a patch it would probably have to be maintained separately. Cheers, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: spNet v0.9.2 released
On Tue, Jun 30, 2009 at 8:52 PM, John P. Dotyj...@noqsi.com wrote: Agreed. But you if you thing gEDA is restricted to generating flat netlists, you don't understand it. You can't improve what you don't understand. [...] You're wrong. Haven't you studied spice-sdb? John, I think everyone here has already got your point. Don't understand me wrong, I'm glad the current solution works for you but I hope you will agree that different people may have different needs. I, for one, am very happy that someone has stepped forward and wrote a netlister that is better suited to my needs. Whether Anthony has reused gnetlist or not - I couldn't care less. I haven't been using it (and thus the whole geda) anyway. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: spNet v0.9.2 released
Hi, The tool works very well (neat example, btw). Couple of observations and nice to have features: - project specific configuration (instead of putting everything in ~/.spnet*), - inferring the list of used libraries by reading ./.gafrc (instead of defining them in ~/.spnetlibs), - command line switches for disabling .END card, for putting top level schematic in a subcircuit, for putting each top-level subcircuit in separate netlists and include them in the top-level one etc. - better attribute names (like modelName instead of value), I guess you are trying to follow some gschem conventions but, to be honest, I don't really care much about compatibility with rest of gschem libraries (they tend to be pcb flow specific anyway), - hierarchical busses and parametrized subcircuits (I've seen this in todo list), - hierarchy configuration from top-level schematic, - FYI, I never use implicit netlisting features (global nets, three pin MOS devices, default channel length). Nevertheless, I've seen people here asking e.g. about .global cards so they might be valuable (unless they get in the way of other features). It would be cool to have some sort of generic netlisting templates for other simulators. I.e. instead of hardcoding spice code in the spnet, these chunks of netlist could be taken from a primitive device library (think: spice view, spectre view, veriloga view etc.). As for the GUI, I don't really miss it too much. Unless it is very elaborate it won't cover even half of features of modern simulators. IMHO, the simplest solution is to add a bunch of components like netlistHeader, netlistFooter, hierarchyConfiguration, runSimCmd or netlisterConfiguration, where the user can simply type missing spice cards, override spnet settings etc. Overall, great job! Thanks. -r. On Tue, Jun 30, 2009 at 8:30 PM, Anthony Shanksyamazak...@gmail.com wrote: That framework of that level of integration I don't think exists of the gEDA flow as written since all of the tools are separate. The easiest way I think this is doable is for there to but a button in gschem that launches an outside script to netlist the current schematic and launch the simulation gui. Before we even think of that level of integration I think there needs to be a real simulation gui (which I am writing) to replace gspicui since it is missing so many feature and is not being updated. On Tue, Jun 30, 2009 at 12:23 PM, Kai-Martin Knaakk...@familieknaak.de wrote: On Tue, 30 Jun 2009 12:08:55 -0700, Anthony Shanks wrote: Thanks I appreciate it. I'm also in the middle of writing a replacement for gspiceui. Are there any plans to reach a level of integration where I can select some subcircuit in gschem and press a simulate button? ---(kaimartin) -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: spNet v0.9.2 released
On Tue, Jun 30, 2009 at 11:10 PM, Anthony Shanksyamazak...@gmail.com wrote: - hierarchy configuration from top-level schematic, What do you mean by this? Say, you want to modify a subcircuit somewhere deep down the hierarchy or use an extracted netlist for some of sub-blocks. If there is no hierarchy configuration, you would have to modify all cells in the design starting from the swapped one up to the top level. With hierarchy configuration, you can specify that the sub-cell should be mapped to a particular cell view/architecture (e.g. extracted or schematic_for_openloop_gain_simulation). If this could be integrated with gschem, so that it knew which schematic it should descend to, that would be perfect. Unfortunately, AFAIK gschem has neither the notion of cell view nor the hierarchy configuration. One idea would be to add a text-like component on the top level schematic, say hierarchyConfiguration, where the user could write something like this: - # original_file_name file_name_to_be_used preamp.sch preamp_for_openloop_sim.sch analoglatch.sch analoglatch_extracted.sp # path_to_instance file_name /X5/X1/something something_else.sch - IMHO, having this information present and displayed on the top level schematic (testbench) is very convenient from the design management point of view. If it was to be added in a GUI or in makefile the information would have to be stored and handled separately. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Standard refdes for a crystal?
Rob Butts wrote: What is the standard refdes for a crystal, I'm blanking? The generic is a U, is this correct? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user Rob, ANSI Y32.16 Reference Designations for Electrical and Electronics Parts and Equipments specifies Y as a crystal refdes. X is supposed to be reserved for sockets. For example, XY2 is a socket for Y2 and XQ1 is a socket for Q1. So, the Wikipedia is correct. HTH Girvin Herr ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: arcs and circles in PCB via gui
DJ Delorie wrote: I was thinking of an edit-arc option that lets you grab the endpoints and drag them to new angles. If you grab the center, it moves the arc. If you grab an enclosing-rectangle-corner, it resizes the arc. http://www.delorie.com/pcb/tmp/arcedit.png ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user DJ, et al, Have you looked at gschem's arc GUI code? That is the way its arcs can be edited. Selecting the arc displays tags on the arc endpoints. Dragging one end (I am not sure which end) rotates the arc around the axis. Dragging the other end changes the length of the arc. Although I have not used PCB yet, I can see advantages to having the PCB and gschem GUIs be consistent. HTH Girvin Herr ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: the joy and sadness of new boards
DJ Delorie wrote: Just got a box of panels from Advanced Circuits. Five panels, ten boards per panel (two each powermeter, usb-gpio pod, and three pod modules - ten sets of boards total). Joy! Unfortunately, I have no way of separating them into individual boards yet. Sadness! But I do have a 60 degree v-scoring bit for my router table. Joy! Last time I used it, the pcbs were too flexible for the big hole the table had around the bit. Sadness! I was thinking of taking an old 7 table saw blade and re-grinding it to a 60 degree point. I can make a zero-clearance insert for it, to ensure correct cuts. Joy! However, I don't have any of the parts for the boards yet. Sadness! But now I get to go through the BOMs, figure out the best parts to use, put together a digikey order, come up with some hobby money, and wait for it all to arrive. Joy! No, wait... sadness? Crap. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user DJ, You don't say, but I assume you have .062 or thinner G10 panels. Do you know anyone with a sheet metal shear? I used that in the past, although the glass fiber is a bit hard on the shear. On the other hand, there is a lot less fiberglass/copper/plastic dust than a saw or router bit. Harbor Freight has a small 30 shear that should be big enough for 15 panels. It is a few hundred dollars to buy it, however. http://www.harborfreight.com/cpi/ctaf/displayitem.taf?Itemnumber=5907 If you are intent on sawing, how about a Dremel cutoff disk? That should be low-cost. Wear a dust mask, though. Girvin ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Using .global statements in GNUcap and mult
On Sun, Mar 15, 2009 at 2:46 AM, al davis ad...@freeelectron.net wrote: [...] Hi Al, This discussion has completely drifted out of the topic I intended to talk about. Please, do not take my comments as an attack on your project - quite opposite, I like Gnucap and I like to use/test it and occasionally dig into its code. My intention was to point out that I, as a Gnucap user, value stability and feature completeness over performance. That's all. It doesn't mean that stability or feature completeness is rubbish, nor it means that I wouldn't like Gnucap be fast. ability to probe signals at lower levels of hierarchy, You can. How to do it without adding probing devices to the circuits? Or, how to save all signals or all classes of signals? Wildcards? Sorry, I really don't know how to do it. Can you give me an example of: - saving all node voltages in the entire circuit, - saving e.g. gm's of all MOS transistors in a given subcircuit. One application with very large circuits that needs a fast simulator is signal integrity. You get huge RC or RLC networks from an extractor, and only care about a few end points, so the output stream is small. (Just a note) That's not necessarily true. In reliability checks it's very common to run simulations on RC extracted netlists saving all device currents and node voltages. I agree this is a niche application but it's also a very important one. BTW, if Gnucap could handle circuits with many small series resistors (tracks) better than Spectre it could potentially hook into this field. Free software is all about community. What features you get depends on who participates in the community, and how they participate. The plugin system is intended to make it easier for casual users to participate in the community. You can participate this way, or by funding some of the work you need. A little bit goes a long way. I wonder if it was possible for you to put Gnucap repository online. Although I'm not competent enough to hack the core of Gnucap (still it would be nice to have a detail change log available), I could write some plugins, add tests/examples etc. Cheers, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [Icarus Verilog] How to synthesis a flip-flop with asynchronous reset
On Wed, Mar 11, 2009 at 11:12 AM, 温宇杰 yujie@celestialsemi.cn wrote: always @(posedge CLK or RESET) begin if (RESET == 1) begin Q = 0; end I don't know much about iverilog but you may want to try this form: always @(posedge CLK or posedge RESET) begin Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Using .global statements in GNUcap and mult
On Mon, Mar 9, 2009 at 6:28 PM, al davis ad...@freeelectron.net wrote: If you are thinking of methods of speeding up a simulation, that has always been a high priority for Gnucap. I know you are now preparing for a stable release, so following concerns are not necessarily valid anymore. I don't think performance is a selling point of Gnucap. Most potential users simply want a functional, feature-rich, open-source circuit simulator. I particularly like the modular design of Gnucap and its planned features (new models, verilog-a, parametrized components). OTOH, what I am missing is some stability and robustness. Think things like not crashing, ability to probe signals at lower levels of hierarchy, working post-processing/measurements, robust operating point analysis etc. As for the simulation performance, there are many things to improve as well. Gnucap still doesn't support gear integration method, its transient simulation time step control is very brittle and output data are saved in non-indexed text files. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Using .global statements in GNUcap and mult
On Tue, Mar 10, 2009 at 2:11 PM, al davis ad...@freeelectron.net wrote: Can you send me some examples of where it crashes? I sent you a bug report recently. As for the newest revision, I haven't tried it yet, sorry. ability to probe signals at lower levels of hierarchy, You can. How to do it without adding probing devices to the circuits? Or, how to save all signals or all classes of signals? robust operating point analysis etc. Can you send me some examples of where it doesn't work? I sent it to you a while ago (an example with a simple CMOS opamp). Your conclusion was that OP analysis failed because of missing homotopy. As for the simulation performance, there are many things to improve as well. Gnucap still doesn't support gear integration method, yes it does. Sorry, I missed this addition. Yes, Gnucap supports gear method. I'm going to try it out soon. its transient simulation time step control is very brittle Really? can you give some examples? I don't have access to the big-bucks simulators for comparison, but in my tests the time step control is consistently better than Spice. Earlier last year I did a bunch of tests using clocked CMOS digital circuit - they tend to exercise time step control quite well. I didn't even need other simulators for comparison - just analysing output data was enough to see how the time step control algorithm performed. It was fairly difficult for me to tune Gnucap options so that it scaled time step reasonably without causing excessive errors or ringing. Again, I'm going try the newest version of Gnucap, including its gear method. and output data are saved in non-indexed text files. Eventually, the output will be through plugins too, so you will be able to add other formats. For now, I had to put a stop to new features to focus on making an official release. That's OK. Perhaps even I can help you with this someday. My point is that it's a bit early to advertise performance of the tool, when many important bits of functionality are still missing. E.g. text file format may be great for simple simulations but it isn't terribly useful for long running simulations (i.e. those which need a fast simulator). BTW., you are probably aware of a renewed interest in high performance analog simulators (not mixed-signal and not fast-spice type). Guys are trying to parallelize as many operations as possible (evaluating models and matrix operations) and optimize all other bottlenecks (time step control, IO). If you want to compete in this field it's going to be tough now. However, even with lower performance Gnucap can still be a very valuable tool as long as it does its job. People often want to run many small simulations in parallel and in such scenario other simulators can be very pricey. Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Using .global statements in GNUcap and mult transistors
On Thu, Mar 5, 2009 at 2:23 AM, al davis ad...@freeelectron.net wrote: The Gnucap behavior is consistent with Hspice and Spectre. At least that is what I have been told. I don't have access to them to check it out. That's incorrect. Both Spectre and Hspice treat devices with m1 as single entities. ok maybe you can help solve this. Well, I'm not sure. I don't know how it is implemented in these simulators. I guess these guys have simply modified the models (they have modified quite a few other things there so I guess they wouldn't have minded adding m parameter as well). Also consider that there are a bunch of parameters that can be probed. Some multiply, some divide, some are not changed. There is no indication in the code of which is which. There could be hundreds of parameters that could be probed. All that is known is a name and the type (real, int, string, ) that it returns. There is no notion of across, through, or anything that helps the decision of how to scale. Perhaps it could be done at the time of stamping the matrix - by multiplying all gm's by a factor of m. Then all the probes would just work. I have no idea how it could be done technically, though. BTW, some simulators preprocess the netlist and reduce parallel devices into a single device with an m parameter set. This gives a huge performance boost in extracted sims. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Using .global statements in GNUcap and mult transistors
On Wed, Mar 4, 2009 at 7:07 AM, al davis ad...@freeelectron.net wrote: like it, for example, I put m=50 to report the full current instead of 1/50 of the current going into it. The Gnucap behavior is consistent with Hspice and Spectre. At least that is what I have been told. I don't have access to them to check it out. That's incorrect. Both Spectre and Hspice treat devices with m1 as single entities. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: How to achive ~90us delay on a digital line
On Mon, Feb 23, 2009 at 7:05 PM, Tamas Szabo sza2k...@freemail.hu wrote: I have been designed an IrDA interface. It works correctly if I connect for example 2 minicom terminal. However I need to communicate with a device, which echoes back all characters, but too fast - so the host side is not ready to receive it (Well, first I designed with HSDL 3602, and it was OK on the breadboard, but HSDL is not available now, thus I redesigned with TFDU 4300, and it has somewhat different characteristic). What exactly is the problem? The device seems capable of operating in such mode (based on its datasheet). In fact, its maximum RX latency is 150us. Why would you like to slow it down further? If it is the UART that is loosing data (just guessing, but that has happened to me before), try sending and receiving data byte for a byte (or up to several bytes ahead for better performance) so the UART's FIFO doesn't overflow. -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Google SoC : Potential Candidate seeking Info
Thank you all for the feedbacks. I looked a bit deeper into the projects and my interests and figured that , I am not into GUI stuff but would love to get my hands more dirty with things even down. On Thu, Feb 12, 2009 at 9:56 AM, al davis ad...@freeelectron.net wrote: 3. Porting of missing analysis, (noise, pz, disto, hb, etc.) from other free simulators (under gnucap) All good projects .. There is someone now working on noise and hb. pz and disto would be good summer projects. pz is fairly easy, if it is based on AC analysis, because the whole model interface is already working. disto is harder because of the model interface. You will learn a lot. Looks interesting now for me. I will look at the current codebase. Is this noise and hb implementation that someone is doing already available in the VCS for me to have a look at and check the pattern of implementation? On Wednesday 11 February 2009, Stephen Williams wrote: Given the apparent bent towards analog in your selection of candidate projects, might I suggest you take a look at the gnucap Code Generator on the Icarus Verilog projects page? This is something that Al has been wanting, and also puts to use some of the nascent analog support in Icarus Verilog proper. I like this one too. It is an enabler that will make other enhancements easier, and something that is desperately needed as a model compiler. There are lots of people who want it and some real experts who can help. This sounds exciting too. But I am highly unsure about the things that I need to learn before taking this project up. The Icarus Project page says this project remains clear of the Iverilog core. It states that one might require knowledge of how to compile models for gnucap. Can some more light be thrown here please? Any nice starting pointers? I can then catch on and start rolling. Thank you once again. With Best Regards, Aanjhan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Made a hierarchical netlister, would like to contribute to gEDA
On Thu, Feb 12, 2009 at 9:17 PM, Yamazaki R2 yamazak...@gmail.com wrote: Hi all, Over the past few weeks Ive been slowly working on a hierarchical netlister wrapper program that uses gnetlist to make a true hierarchical spice netlist. This is a great news. It has a lot of missing features that I want to have soon and requires some things from the gschem schematics to properly work, but I'll be working on slowly removing those dependancies so it's more standalone. I also want to either work on integrating the code to genetlist or removing the requirement for it completely. Are you extending gnetlist or writing your own netlister from scratch? (for me any is OK). I'm not a programmer and have been literally learning C as I go (I already knew the basically since Ive programmed in other languages before). Arguably, C is not best suited for text processing, both Perl or Python would make your job far easier. Of course if you are working on gnetlist you are limited to C+Scheme. How do I contibute my code to the gEDA repository and maybe have others contribute? I have never contributed to a open source project before so I don't know how this works. How about placing your code on sourceforge or google code so that anyone interested can look at it? Thanks, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Google SoC : Potential Candidate seeking Info
Dear All, I am Aanjhan doing my Masters in Electronics at EPFL, Lausanne, Switzerland. A short introduction about me is present in the page https://wiki.ubuntu.com/Aanjhan I am part of the Fedora Electronics Laboratory team and also help in keeping in sync with the packages in Ubuntu as part of the MOTU Science team. Having looked into the projects listed for GSoC 2009, I am interested in the following projects and would like to know the pre-requisites for taking them up. My skillsets are C, Verilog, VHDL and bit of Python and Perl. Am open to learn new languages too given that there is some time for the preparation phase before the proposals for GSoC needs to be put up. The projects that am interested in are as follows (not in any specific order): 1. Usability improvements for ngspice/Gnucap - Under gaf 2. More interesting integrations with other tools. The new Tcl interface adds a bunch of possibilities. I know one guy is using it to allow remote control from emacs through a bridge server. (Under GTKWAVE - I would like to know if htere are specific interesting integrations as I am not getting the whole picture behind this project proposal) 3. Porting of missing analysis, (noise, pz, disto, hb, etc.) from other free simulators (under gnucap) 4. Add uwire (unresolved net) support - Under Icarus The above are projects that I liked at first glance. If I have missed something that the mentors here think it would be interesting for me, I am open to those ideas too. Awaiting further guidance. Thanks and Regards, -- Aanjhan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: GTK RANT
On Mon, Jan 26, 2009 at 2:39 PM, Peter Clifton pc...@cam.ac.uk wrote: It wasn't so long ago that gschem added more standard keybindings as default for the Copy+Paste actions. I'm sure no-one would argue that was a bad thing, or that users ought to fix those themselves. There is no doubt no defaults will ever satisfy everyone, not in EDA. I think best what gEDA could do is: - use sane defaults, perhaps favouring inexperienced users, - make changing settings easy, e.g. by selecting (in GUI) predefined keymaps that emulate other popular EDA packages. *Personally*, I'm not a big fan of two-key shortcuts. They tend to slow down navigation and editing quite a bit. OTOH, I don't care much about less frequent actions - I wouldn't even mind if these were only accessible from the menu. Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnucap questions
On Thu, Jan 22, 2009 at 5:21 PM, al davis ad...@freeelectron.net wrote: Gnucap verilog mode doesn't yet accept statements split across lines. That will be fixed. Even when that is fixed,I still think the netlister should put statements on one line for readability. Does Gnucap use any hard-coded text buffers? What happens if you give it an instance with e.g. 1 pins? Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [RFC 1/6] Non-Turing-complete configuration files.
On Sat, Jan 17, 2009 at 5:08 PM, Peter Clifton pc...@cam.ac.uk wrote: Sorry if I will be too long, but this is an important question. Short version: Don't Do That! Rebuttal: Least important reason: Turing complete may present security implications. (BTW: Just saying sandbox the interpreter is very easy. Actually doing it properly is another matter.) Well, when it comes to security nothing is easy. But writing a safe sandboxed Scheme interpreter is not more difficult than writing a safe configuration parser. Both solutions share same two risks: parsing (especially when implemented in C) and accessing exposed primitives/variables. Real crux of the matter: If you accept free-form input, it becomes inordinately more difficult to write any sane GUI, or write-back of changed config options. (Since the config file might be arbitrarily complex). Fair enough. I'm not particularly attached to the current configuration mechanism (although setting callbacks without this could be difficult). I just don't think it is broken or particularly needs an improvement. Actually, this is currently one of the gEDA's strongest points. Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [RFC 1/6] Non-Turing-complete configuration files.
On Fri, Jan 16, 2009 at 10:44 PM, Peter TB Brett pe...@peter-b.co.uk wrote: Currently, the gEDA configuration files are executed by a Scheme interpreter. This has a number of flaws: 1. An error in a configuration file will cause it not to be fully interpreted. This can potentially leave gEDA applications in an unusable state or even cause it not to start at all. Furthermore, this can be confusing to a new user, who might not be familiar with Scheme or the quirks of gEDA configuration and thus more at risk of making mistakes configuring gEDA. Having a scripting language at hand is one of the most important features of gEDA. At the moment this feature is not sufficiently exploited because of limited API and perhaps poor implementation (guile) but removing it would IMHO be a mistake. The way to make it more user friendly is to improve and clean up the API exposed to the user. 2. Per-project configuration files may legitimately be required. For instance, they may be used to customize libraries of symbols or hierarchical schematics. However, they currently pose a security risk in that downloading and opening a set of schematics from the Internet can easily result in arbitrary code being executed. That's a real problem. Personally, I'd like gEDA not to bother with security at all, not at this stage at least, and allow scripting even in user's data (so that the user could parametrize his/her design more flexibly). This BTW could be done safely by sandboxing the language, i.e. by interpreting it in its own environment and exposing only limited functionality (access to the component and parent component parameters, math functionsconstants, perhaps flow control structures) to the user. Such a limited Scheme interpreter can be implemented safely and quite easily in Scheme itself. As far as configuration files are concerned - control is more important than security. Besides, being able to set an arbitrary variable is not much safer than executing a guile script. My proposal is to use a Scheme-like syntax for the configuration files, but to parse rather than execute them. Naturally, it would be necessary to design the system carefully to ensure that all configuration parameters can be specified in the reduced syntax. I think this will only shift complexity and security problems to external scripts and make gEDA itself less flexible. -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: [RFC 2/6] Plugin system
On Fri, Jan 16, 2009 at 10:44 PM, Peter TB Brett pe...@peter-b.co.uk wrote: Currently, Scheme is the only available extension language for gEDA. However, in future it may be desirable to extend gEDA apps in other languages, including possibly as native code loaded from .so files. Extending gEDA with native code plugins makes IMHO little sense. There are no particular performance requirements in gEDA, and even if are, it's usually easier and better to patch the source code. OTOH, scripts *are* useful. GEDA already comes with a scheme interpreter built-in and I think this should remain a default option. Not because Scheme is the best language in the world but because it is a reasonable one, a lot of code has already been written in it and introducing yet another language in the default distribution would only add to the complexity. As for other scripting languages, it's probably best to export gEDA API over DBUS and allow external scripts to talk to gEDA tools directly. This would free us from implementing yet another plugin/RPC system. At this stage, improving the API itself is IMHO far more important. Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power (and other non-graphical) pins
On Tue, Jan 13, 2009 at 8:47 PM, Joerg joerg...@analogconsultants.com wrote: The backplanes in our ultrasound systems are usually north of 4000 pins and I have never seen a case where there was not a schematic for that. In analog IC design it's fairly easy to get schematics even bigger than this - that's what you get when you extract the layout. Sure, transistor level netlist would do fine for simulation but it is simply convenient to have an extracted schematic of the cell (if only for netlisting, DRC checks, manually finding some internal devices/nodes). Ok, if gEDA is geared towards ASIC/FPGA that's different. Then it sure won't be my kind of tool, just like BAE isn't (had tried it out lately). Believe it or not, gEDA actually strongly focuses on the PCB flow. Just look at the symbol attributes - pin numbers, footprints, even reference designators come in PCB flavor. There is only partial support for the design hierarchy, partial support for libraries, partial support for other types of design data (RTL, netlists), no functional netlisters, no DRC checks on the design. These issues can often be fixed using external tools (makefiles, own netlisters and rule checkers) but they are enough to discourage most designers from even trying the tool. To be honest, looking at the traffic on this list, I thought the PCB flow support is fairly decent (or the only one that works, for that matter). BTW, analog IC guys long since have given up using implicit power connections and multi-slot symbols. People simply draw all the power lines just like any other wires (sometimes even explicitly modeling them with L/R/C circuits). Same with the cells (symbols in the PCB world) - the closer the symbol is to its schematic/RTL/layout/extracted view, the better, if only for LVS-ing the design or juggling with schematic/extracted views in simulations - multiple slots only add unnecessary complexity to the design. Such schematics are perhaps a bit more difficult to understand but easier to work with. Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Power (and other non-graphical) pins
On Wed, Jan 14, 2009 at 12:53 AM, Joerg joerg...@analogconsultants.com wrote: Yes, because you guys don't have to pay 2-3c for each additional transistor or 5c per FET :-) At least not for those working. :-) But it'll electromigrate itself to death in less than a year ... It only has to live a couple of hours ... Oh. Lucky you! In some of our circuits (mostly in RF blocks) getting the layout electromigration clean was really painful. It's not only because of the layout (although this stuff can grow pretty big) but also performance - adding several fat connections with their parasitics can kill otherwise carefully crafted circuit. The verification method is also a major pain in ass. We have learned the hard way to anticipate these problems early, and to employ various sometimes non-obvious tricks to work them around. And that's only one problem, what about decoupling, multiple power domains (for noise filtering and for power-down functions), well biasing, voltage drops, ringing and ESD protection? Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Wish list, sort of
On Tue, Jan 6, 2009 at 12:45 PM, Werner Hoch werner...@gmx.de wrote: My database are just some ini-style files that contain some attributes and other definitions. A python script combines the definitions and template symbols to complete symbols. I've only a few parts (1000 to 1500) mostly diodes and transistors with spice models. I haven't played with a real database like mysql. This looks very interesting. I spotted this mechanism before but assumed this is just yet another way of accessing symbols. Can you explain how do you tie symbols with their respective spice models? Can you switch between different models by configuration? If this virtual library could store both symbols and schematics (as well as netlists, models, ...) that would be great. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Wish list, sort of
On Tue, Jan 6, 2009 at 9:23 PM, Werner Hoch werner...@gmx.de wrote: The [GLOBAL] section defines some pathnames, ... All other sections are attributs of devices, where all attributes and values for the symbol are defined. With the get command gschem can ask for a symbol. The python script will then put the values of the requested symbol section into a symbol template. (using the python moduls string.Template and ConfigParser) The script writes the complete symbol to stdout and gschem receives the symbol. So it's like a parametrized cell. Nice. Why would you like to store schematics in that database? Or Netlists? Sounds strange to me. A cell is much more than just a symbol. Look at electric (it's on GPL btw) http://www.staticfreesoft.com/ (I don't advocate a binary-blob type database here - using text files in directories is perfectly fine for me) - it has libraries, which contain cells, which consist of multiple views (symbol, schematic, layout and so on). Other tools often include netlister specific views, like *spice, cdl, verilog, vhdl, etc. The whole hierarchy is not tied with attributes - most design tools have a notion of hierarchy configuration (let's simulate this circuit with this cell extracted from the layout, instead of a schematic). Sure I can do this with make, but this lefts gschem completely unaware of the design hierarchy (or, worse, it can get it wrong if there is a mismatch between source= attributes and the makefile). A potential solution (or workaround, depending how to look at this) would be a tool, similar to yours, that based on a configuration or a convention dynamically overwrites the symbols so that gschem knows where to get their schematics from. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: EDIF standard?
On Mon, Jan 5, 2009 at 6:21 PM, Árpád Magosányi mag...@rabic.org wrote: I am interested in the EDIF file format standard. Perhaps this can of use for you: http://www.rulabinsky.com/cavd/text/chapd.html There are many aspects of the EDIF format which are left undefined in the standard. This makes implementing it quite tricky - you'd need to compare your implementation with others (which can be far more expensive than the standard itself). I have found it at the ansii download site, but the price is prohibitely high for me (and I find ridiculous to ask money for standard documents anyways). The price is $388.00 for IEC 61690-2 (EDIF-4) for a single user license (of the document itself, it looks like there is no NDA required). I agree this is quite a lot of money, especially if you are writing free software. Still, the standard is there, available for everybody. Perhaps this is where a donation system or a foundation (GNU?) could help. regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Wish list for gschem
On Mon, Jan 5, 2009 at 8:42 PM, Stuart Brorson s...@cloud9.net wrote: U. try putting a .gschemrc in your local $HOME/.gEDA directory, and then putting your favorite key bindings in there. You are right. It looks like keymap can already be switched by redefining current-keymap. It think the problem I hit in the past was actually changing the menu (once added by add-menu it cannot be removed nor changed). In gschem-1.4.0 (Ubuntu) redefining a menu that was already added causes gschem to segfault. Not sure if that's a known error. See the example user config file below: (define help-menu-items '( (gEDA Documentation... help-manual help-manual) (gschem FAQ... help-faq help-faq) (gEDA Wiki... help-wiki help-wiki) (Component Documentation...hierarchy-documentation hierarchy-documentation) (SEPARATOR no-action no-action) (Hotkeys...help-hotkeyshelp-hotkeys) (About... help-about help-about))) Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Wish list, sort of
On Mon, Jan 5, 2009 at 10:02 PM, Mike Crowe mcr...@gcdataconcepts.com wrote: There was talk a while ago about integrating gschem with a database. Any status change on that? Any way I can help implement/test with mysql? What do you mean by integration with database? AFAIR there were two database-related ideas discussed here: - attaching to a (online?) symbol database. I don't know details - that's PCB guys' toy. - storing design data in a database. IMHO a good idea but not very popular here. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: EDIF standard?
On Mon, Jan 5, 2009 at 9:55 PM, Dave N6NZ n...@arrl.net wrote: EDIF still exists? Ouch. EDIF == Every Disk Is Full. EDIF is grammatically an incredibly verbose file format, and lexically inefficient as well. It is also pretty nasty to parse -- very unfriendly for LALR parsing like flex/bison can do for you. EDIF failed to meet its goal of a universal EDA exchange format but it wasn't caused by its weaknesses. It was the whole idea of one format fits all that failed. EDA packages use completely different abstractions for multiple basic constructs (not to say about more advanced ones) and the effect is that EDIF can only be treated as a lowest common denominator import/export format (and lowest means *really* low here). Even though it's not terribly useful there are currently no other formats for exchanging e.g. schematics. Sure, there is OpenAccess but it's more an API than a format and it still imposes some design decisions just like EDIF did. EDIF is fairly widely adopted as a *netlist* exchange format (although structural verilog is more popular now). It's easy to parse (BTW, using bison here would be an overkill) and is as compact as any other text netlist format can be (or better, if compared to VHDL). For a synthesis tool, it currenlty makes more sense to input/output data in verilog. Its structural subset is not much more complicated than EDIF and at very least can be directly simulated (especially if assisted with SDF). Several years ago verilog was not very well supported by some FPGA backend tools but that might have changed by now. Regards, -r ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: undo and zoom/view functions in gschem
On Thu, Nov 27, 2008 at 2:46 PM, Stefan Salewski [EMAIL PROTECTED] wrote: Am Donnerstag, den 27.11.2008, 08:30 + schrieb Peter TB Brett: It's been like that since early 2005, at the very least. I find it quite useful sometimes. It's very useful (especially for layout editors or waveform viewers, less for schematic editors) but it should rather use a separate view stack (not an editing command stack) as in gschem. This is at least how it is implemented in some other tools. I think long time ago I suggested two (or more?) zoom states, i.e. SHIFT F1: Store current view1 SHIFT F2: Store current view2 F1: Show view1 F2: Show view2 F3: Toggle between view1 and view2. That's a good idea but it's probably difficult to make it general enough for everybody. That's why gschem has a built-in scheme interpreter, it should be easy enough to implement this function as a scheme script and bind it to a key. I still think that this may be useful for gschem and pcb. I am using quite a few scripts like this. Again, it's mostly useful for layout editors when you want to switch many settings (visible layers, rendering depth, modes, tool parameters, snap grids etc.) on the fly. It's a matter of a task complexity vs. tool complexity trade-off. Perhaps it could be generalized as a save/restore configuration options function but it still wouldn't be as flexible scripts. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some kind of library manager and hierarchical netlisting
On Fri, Nov 21, 2008 at 6:08 AM, Paul Tan [EMAIL PROTECTED] wrote: 1) Add the following 2 lines to the end of any one of the gnetlistrc files, such as the system-gnetlistrc file or your '$HOME/.gEDA/gnetlistrc file (make sure to leave an extra empty line after that): (if (assoc hier_trav_disabled (gnetlist:get-calling-flags)) (hierarchy-traversal disabled)) I like it. Is it possible to add this option to the gnetlist distribution? Do you know if gnetlist can print out to its stdout a list of files in the design hierarchy? That could eliminate the need to specify it manually in Makefile. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some kind of library manager and hierarchical netlisting
On Thu, Nov 20, 2008 at 6:33 PM, John Doty [EMAIL PROTECTED] wrote: Can you explain in detail how do you generate the hierarchical netlist? Here's a simplified version of my current flow. Thanks! I'll try it. This method looks pretty good. 1. Don't use source= in your symbols. That's bad and good. Bad because it disables hierarchical design support in gschem (= you no longer can navigate to subcircuits in gschem). Good because all the design configuration is stored in only one place (Makefile). 5. For multipage schematics the generic rule won't work, need to make an explicit rule, but it's easy: foo.cir : foo.1.sch foo.2.sch $(GNET) No problem here. Out of curiosity, what do you use multi-page schematics for in the IC design? Although using Makefile doesn't seem particularly appealing to me (I keep all my design data in a single place - schematics) Huh? Schematics are a graphical representation of a netlist. There is so much more that goes into a design. Requirements, high level simulation and optimization code, descriptive documentation, etc. I keep all these, except maybe for optimization code, separately from design data. The only exception is end-user documentation that itself is a part of the product/design. Even for netlists, schematics are sometimes a second-rate representation. A drawing of a backplane that has nothing but a bunch of 100 pin connectors on it is pretty useless, but connector pinlists are nice source files both for netlists and text documentation. I agree. However, the tools I use at my job, handle such a mixed design environment quite well. It's a *trivial* hassle. It's like the engineer who wouldn't use the signal generator because its output was a type N, and he would only use BNC's. Get over it. Get an adapter. gEDA is an extremely flexible toolkit, adaptable to many flows. It's your job to do the tiny amount of thinking needed to adapt it to *your* flow. The alternative is something too inflexible to adapt at all. But with gEDA, as with many good things, a little resourcefulness goes a long way. I feel I need to explain something. There is nothing wrong with scripting the design flow. In fact, I do this all the time. However, scripting is only good at the development stage when people want to streamline their own boring job. Once they are done with this, the result must be as self-contained as possible. If there is a build script used it must be tested, documented etc., because it becomes a part of the product. This Makefile-based flow is not different, although it's simpler than I expected. Finally, there is no magic in netlisting. This, except for drawing schematics, is a basic function users normally expect from any design entry tool. Netlisting the design really is not the place where Makefile should be _required_. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some kind of library manager and hierarchical netlisting
Hi, I hit exactly same issues last time I tried to use gschem/gnetlist. The flow simply doesn't work with hierarchical designs (and yes, there is no notion of a design library in geda). If you are willing to spend some time on it and contribute fixes to the flow that would be great. On the other hand, if you are mostly interested in circuit simulation try ltpice(+wine). Regards, -R. On Tue, Nov 18, 2008 at 11:27 PM, Yamazaki R2 [EMAIL PROTECTED] wrote: Has anybody made some kind of library manager like the cadence library manager in icfb to manage schematics and symbols? Something where in the schematic editor I can type in a library name and cell name it and automatically instantiates the symbol/schematic combo in the hierarchy? Also, I know by default the gnetlist program does not contain a scheme that can do hierarchical netlisting, but has anybody in the community made a scheme that can do hierarchical netlisting? Thanks ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some kind of library manager and hierarchical netlisting
On Wed, Nov 19, 2008 at 2:49 PM, Peter Clifton [EMAIL PROTECTED] wrote: On Wed, 2008-11-19 at 06:04 -0800, Steve Meier wrote: Peter, I believe that gnetlist takes in a hierarchical series of schematics and flattens the schematics into a flat netlist that may then be exported into a number of flat formats. In other words the net has been flattened before reaching the backend. Hierarchical information is retained in reference designators and in net names. You are, of course, correct. IIRC, there were a few workarounds for the VHDL / spice backends, where individual pieces were netlisted separately. Its been a while since I looked, and certainly those cases are non-optimal, even if it is possible to retain hierarchy. Agreed. I didn't mean gnetlist doesn't work with hierarchical designs at all - it just didn't produce any useful results last time I tried it. I've looked into the scheme code but I couldn't find any obvious errors. This single error broke my workflow, I think it is important enough to inform others that they should not rely on this particular feature. There are possibly some workarounds available, such as net-listing individual pieces separately, but we (gEDA) really ought to work on doing better. IMHO netlister front-end should be included in libgeda (for example as an iterator returning all the pins, nets, primitives, subcells in the design). It is a single best place to locate all the logic translating graphical shapes/file format into a circuit. Otherwise every tool has to reimplement this logic from scratch based on conventions. Such a circuit information would also be very useful for gschem itself - it would be possible, for example, to perform some sanity checks (pin mismatches, shorts, unconnected nets etc) or assist the designer (highlighting nets). Best regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some kind of library manager and hierarchical netlisting
On Wed, Nov 19, 2008 at 11:54 PM, John Griessen [EMAIL PROTECTED] wrote: Peter Clifton wrote: That simply is not true. The netlister _does_ work with hierarchical designs, but typically, our back-ends target a flat output, such as for PCB. Don't worry about him. I suspect he's one of the poisonous people you run across in open software development. haven't looked at the video Al suggested yet, but planning on it. Good for you. Just wanted to say that the primary reason I don't contribute to geda is not its set of features or any problems with its codebase but the community. There are exceptions, of course, (Peter, Werner, Ales, sorry if I forgot someone) who are open to exchange ideas but more often than not people here are hostile to anything that isn't a blind praise for the project. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Some kind of library manager and hierarchical netlisting
On Thu, Nov 20, 2008 at 1:09 AM, John Doty [EMAIL PROTECTED] wrote: Agreed. I didn't mean gnetlist doesn't work with hierarchical designs at all - it just didn't produce any useful results last time I tried it. You haven't clearly stated what your problem was. I've done both hierarchical VLSI designs (SPICE style: generate a hierarchical netlist with a Makefile and let the downstream tools flatten it), and circuit boards (use source= and let gnetlist do the flattening). Works great for me. Nobody can fix a problem you can't clearly articulate. Can you explain in detail how do you generate the hierarchical netlist? Although using Makefile doesn't seem particularly appealing to me (I keep all my design data in a single place - schematics) it could potentially make the flow working until the proper netlister is done. I've looked into the scheme code but I couldn't find any obvious errors. This single error broke my workflow, I think it is important enough to inform others that they should not rely on this particular feature. What error? We discussed several issues here: http://archives.seul.org/geda/user/Jan-2008/msg00249.html Please accept my appologies if those have already been fixed - I haven't used gnetlist since that time. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Slotting and visible power connections
On Fri, Nov 7, 2008 at 5:44 PM, Kai-Martin Knaak [EMAIL PROTECTED] wrote: On Fri, 07 Nov 2008 12:37:30 +0100, Stephan Boettcher wrote: Why do you want power symbols? Analog circuits require dedicated capacitors at the power pins. I agree. In analog IC design (this is my field) things went both a bit further and in slightly different direction. People are partitioning schematics exactly as they would partition the layout (using a design hierarchy). This implies that slotted symbols may not be used, even in situations where it would make sense (e.g. an integrated multichannel cell). It is not uncommon to model supply or critical signal tracks explicitly to handle signal integrity issues, supply/ground noise etc. The main difference from the component-level world is that in the IC design tools are strongly focused on simulation, both of the schematics and the layout. Typical designs are also more complex so it is better not to rely on the layout designer intuition (even if it is the same person as the circuit designer). Implicit pins are commonly forbidden. I've even seen guidelines prohibiting implicit net connections (by named nets) or large flat schematics (say, larger than an A3 size page). These problems are slowly drifting to the component-level world. Slotted devices almost don't exist (except maybe for 74XXX type devices) and even if they do, it's is still better to instantiate them explicitly (like using e a single symbol for a 4x opamp). Simulation becomes a part of the design flow, at least for parts of the system, as well as does the extraction of the PCB parasitics. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attributes in pcb footprint files -- is this a new feature?
On Jan 28, 2008 6:07 PM, DJ Delorie [EMAIL PROTECTED] wrote: What can these attributes be used for? Board level: * copyright and authorship notices * global state for plug-ins * DRC rules, post-processing settings, etc. * historical or tracking info (rcs tags?) Element level: All that plus... * origin * rotation * location of documentation Etc. I.e. Use your imagination :-) Borrowing from ASIC flow: width/length, number of pins. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Attributes in pcb footprint files -- is this a new feature?
On Jan 28, 2008 10:49 PM, DJ Delorie [EMAIL PROTECTED] wrote: Borrowing from ASIC flow: width/length, number of pins. Hmmm... elements should already know this; they have a bounding box and they can just count their pins. They don't need to know it in a general case. This is called a parametrized component/cell in the ASIC world. The cell contains some script code that reads the instance attribute value and modifies the layout of the cell accordingly. Whether it is useful for PCB or not - it's up to you. In the ASIC flow primitive devices (and sometimes some more complex blocks as well) are very often laid out this way. This greatly reduces number of cell variants - just imagine having transistor of different widths, lengths, that are butting or not butting other transistors, having different contact configurations, well-tap shapes, well types, metal interconnections connections etc. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice netlister
On Jan 21, 2008 6:02 PM, John Doty [EMAIL PROTECTED] wrote: On Jan 21, 2008, at 10:43 AM, John Griessen wrote: John Doty wrote: - clean schematics are needed for LVS, What's LVS? Please don't assume we know your jargon. Layout Versus Schematic checker. EDA jargon. Chip design jargon. Our jargon. The people I work with call it postlayout verification, and the schematic isn't directly involved: we do it at the netlist level. I don't see how you'd do it at the schematic level: the extracted netlists from the layout correspond to schematics that are humanly incomprehensible! But again, I am very far from the VLSI mainstream. That's a bit off-topic but it's better if I explain this topic a bit. LVS is a method of comparing layout vs. schematics. It starts with two netlists - one obtained from schematics (usually a spice-like .cdl format, verilog gate-level netlists for logic), the other extracted from layout (without parasitics). In fact, you can compare netlists obtained from two schematics (sometimes it's called SVS) or two layout (this is rarely used - layouts are usually compared geometrically). It's basically a tool, which says that the layout you have drawn is same as schematics you have started from (in terms of primitive devices used and their interconnections). LVS is one of _layout_ verification methods. Others are DRC (often separated into several checks: antenna, density etc), ERC, LVL (GDS compare). Post-layout verification refers usually to the extracted circuit simulations. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice netlister
On Jan 21, 2008 8:47 PM, John Doty [EMAIL PROTECTED] wrote: It seems like netlists, not schematics, are the basis here. I don't see why that is at all a problem for gEDA as currently structured. Either a separate tool or a gnetlist back end could do this. I don't see why you think a spice-subcircuit-LL component could get in the way here. I don't want to put backend specific components on the schematic. If the spice-subcircuit-LL is _the_ way of making hierarchical schematics, and spice-subcircuit-IO is _the_ way of connecting them, then I have no objections against using them. But for now they look strongly tied to the spice-sdb backend only. I don't know what open source tools exist here. It would be interesting to investigate incorporating them into a gEDA flow. The flow is very rigid. You still _have to_ use the blessed flow, at least for sign-off. Sure, you can use some cheaper tools meantime but to really make a difference these tools would have to be 100% compatible with rule sets provided by the fab and work reasonably well. Very similar thing happens with simulators. For sign-off you _must_ use the simulator (often in a specific version) your fab requires (together with their models). Otherwise, in the best case, you are left without support. Good place for gEDA to start spreading in this industry is to concentrate on design entry tools (schematics editor, netlisters), logic simulators and data viewers (simulation results etc). This is because these tools are relatively simple, non-critical, easy to adopt and its commercial counterparts can be expensive. Analog simulation is a next step - this is more difficult because of higher compatibility requirements but still it would be possible to compete with commercial simulators by price. Often it is necessary to start a large number of simulations and then number of licenses becomes an issue. (BTW. that's one of reasons why I would like to see monte-carlo analysis in gnucap). Then, once the deployment barrier is broken, there would be more interest in building up on top of gEDA. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple user libraries, parametrized components
On Jan 20, 2008 12:16 AM, Kai-Martin Knaak [EMAIL PROTECTED] wrote: On Sat, 19 Jan 2008 20:24:42 +, a r wrote: First of all: What do you refer to by cell? A schematic symbol, or a pcb footprint? As John said, I referred to any kind of data that belongs to a particular block or component 1. Library search path, or rather some kind of a project file that contains a list of libraries, is a good idea. There is a multitude of rc files that can be read on start-up of gschem or gsch2pcb. gafrc and gschrc can be definied on system, on user and on project level. My gafrc typically contains the following lines: /--gafrc- ;(reset-component-library) ; don't use system symbols ;(reset-source-library) ; don't use system footprints ; Allow to source symbols from the current working directory (define current-working-directory (getenv PWD)) (component-library current-working-directory) (source-library current-working-directory) (source-library /home/kmk/lilalaser/geda/kmk-pcb) (component-library /home/kmk/geda/kmk-sym) (component-library /home/kmk/geda/kmk-sym/analog) (component-library /home/kmk/geda/kmk-sym/digital) (component-library /home/kmk/geda/kmk-sym/connector) (component-library /home/kmk/geda/kmk-sym/analog/diode) (component-library /home/kmk/geda/kmk-sym/misc) (component-library /home/kmk/geda/kmk-sym/titleblock) (component-library /home/kmk/geda/kmk-sym/power) \ It works! Thanks. I wasn't aware that I can add multiple libraries this way. In fact, it might be a bug here - when library name parameter is used: (component-library ./test1 test1) (source-library ./test1 test1) (component-library ./test2 test2) (source-library ./test2 test2) only test1 library is visible in the component browser. 2. Component browser (and file open dialog) should display all defined libraries and all cells from these libraries should be accessible. This is already the case. I mean, there is some inconsistency here. Why not to use a component browser instead of file open dialog? The file open dialog in its current shape could be used as an open project file or an add to the project dialog. 3. Cell name conflicts should be resolved by: a) searching in the current library (i.e. one that contains a referencing/parent cell), I don't quite get, what you mean by current library. 1. Say I have lib1 and lib2 libraries added. For some reason the search order is reversed, i.e. first lib2 is searched, then lib1. 2. I have a set of schematics and symbols in lib1 and lib2. All those cells are same (well, I added some annotations to be able to distinguish cells from lib1 and lib2), 3. Cells in each library are arranged hierarchically (in the same way as in gTAG example cell are arranged). Now: 4. I open top-level schematics from lib1. 5. (surprise) It refers to subcells from lib2 (not its own cells in lib1). b) if (a) fails, by searching in other libraries in the order defined in the library search path or a project configuration file. This is how library search is done right now. Yes. I would greatly prefer to seach cells in the current library (i.e. the same library as a parent cell). BTW, I haven't looked at PCB yet. Does it support hierarchical designs? -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Spice netlister
Hi, Is it possible to setup gnetlist (gnetlist -g spice-sdb) so that it won't add .END at the end of the spice netlist? In my flow, I usually prepare a testbench file manually and from here I include a (clean, without simulation commands) netlist. However, that .END makes this flow awkward. Sure, I can do it the other way around or postprocess the netlist but it's an additional hassle. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice netlister
On Jan 20, 2008 12:19 PM, Peter Clifton [EMAIL PROTECTED] wrote: Find this code, which is around line 1878, and comment out the line outputting the .end. I presume the .ends code is still useful.: Thanks. ;; ;; Now write out .END(S) of netlist, depending upon whether this schematic is a ;; normal schematic or a .SUBCKT. ;; (if (not (string=? schematic-type normal schematic)) (begin (spice-sdb:write-bottom-footer (string-append .ends model-name) port) (display ***\n port) ) (spice-sdb:write-bottom-footer .end port) ) I have looked closer into the sources and into the RF_Amp example circuit. If a spice-subcircuit-LL component is added to the schematic the netlister will wrap it up with a .subckt/.ends cards. That's pretty close to the behaviour I wanted. There are some issues, though: 1. It forces me to add a simulation card to the schematic. In general cases that something I'd like to avoid (it is OK for testbench schematics, though). 2. All nested models or .include cards (if -I option was used) are added inside the .subckt. That may cause problems with spice simulators that do not like such nested constructs. 3. There are special spice-subcircuit-IO components used for making subcircuit pins. Does it mean the netlister cannot cope with normal instance pins? -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice netlister
On Jan 20, 2008 4:36 PM, al davis [EMAIL PROTECTED] wrote: In my flow, I usually prepare a testbench file manually and from here I include a (clean, without simulation commands) netlist. However, that .END makes this flow awkward. Sure, I can do it the other way around or postprocess the netlist but it's an additional hassle. I usually need to edit the generated netlist. If not this, it is something else. I also usually need to do the schematic in a way a little different than I want, to make the netlister happy. Editing netlists is evil. I really want to have all design data on schematics. Postprocessing the netlist is error prone and you may easily end up simulating different circuit than you entered in your schematic editor. Sure, it's not a problem with simple designs but in real life you rarely go below several tens of hierarchically arranged cells. The other netlisters have problems too .. The Verilog netlister does not pass attributes. The VHDL netlister gets the pin names wrong. I have just tried the spice netlister with a trivial hierarchical design (a circuit that contains subcircuit that contains a MOS transistor). This was just before Stuart sent his mail. Here is what I got: * gnetlist -I -g spice-sdb -o top.net lib3/top.sch * * Spice file generated by gnetlist * * spice-sdb version 4.28.2007 by SDB -- * * provides advanced spice netlisting capability.* * Documentation at http://www.brorson.com/gEDA/SPICE/ * * *== Begin SPICE netlist of main design M1/M1 1 3 2 2 nmos4 l=3u w=1u S 2 No valid value attribute found G 3 No valid value attribute found D 1 unknown .end I wouldn't even know where to start I wanted to fix it. It simply looks totally wrong. Flattened (?) subcircuits, lost net names, some garbage. The .end clause seems to be the least issue here. Sorry if that sounds like bashing again. There is quite impressive amount of code in both gnetlist and its backends. But something went wrong with them. I just can't help the feeling that it woudn't take more than 2 days hacking to write a perl script generating a valid spice netlist. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice netlister
On Jan 20, 2008 6:17 PM, Stuart Brorson [EMAIL PROTECTED] wrote: I have just tried the spice netlister with a trivial hierarchical design (a circuit that contains subcircuit that contains a MOS transistor). This was just before Stuart sent his mail. I'd be curious to see what happens if you try some of the suggestions in my e-mail. In particular, using Makefiles to manage large projects -- rather than some built-in facilities of the EDA program itself -- is one of the strengths of the gEDA approach, once you get used to it. I use make (well, in fact it's custom equivalent). But using it just for netlisting is simply an overkill. I would rather write my own custom netlister instead. Yes, I realize that many folks want the tool to do everything, but that's not how gEDA currently works. Rather, we try to exploit gEDA's openness, and leverage other unix tools to help create designs. We try to follow the unix philosophy of having small tools which do one thing well, and then use scripts and other glue to build larger workflows. It's not what some people expect nowadays, since they've become used to the Windows application everything *and* the kitchen sink philosophy. Well, I need a netlister. HERE is what I got: * gnetlist -I -g spice-sdb -o top.net lib3/top.sch * * Spice file generated by gnetlist * * spice-sdb version 4.28.2007 by SDB -- * * provides advanced spice netlisting capability.* * Documentation at http://www.brorson.com/gEDA/SPICE/ * * *== Begin SPICE netlist of main design M1/M1 1 3 2 2 nmos4 l=3u w=1u S 2 No valid value attribute found G 3 No valid value attribute found D 1 unknown .end H. It would be interesting to see the schematic which produced this netlist. I have attached it to this mail. -r. test.tar.gz Description: GNU Zip compressed data ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Spice netlister
On Jan 20, 2008 6:19 PM, John Doty [EMAIL PROTECTED] wrote: On Jan 20, 2008, at 6:51 AM, a r wrote: 1. It forces me to add a simulation card to the schematic. In general cases that something I'd like to avoid (it is OK for testbench schematics, though). I don't see why that's a big deal. - clean schematics are needed for LVS, - different simulators are used. 2. All nested models or .include cards (if -I option was used) are added inside the .subckt. That may cause problems with spice simulators that do not like such nested constructs. Indeed, that's an annoyance, not only for simulation but for layout. The layout contractor I work with wants to see each cell in the netlist exactly once, at top level, not nested. But a little postprocessing gets the job done here. 3. There are special spice-subcircuit-IO components used for making subcircuit pins. Does it mean the netlister cannot cope with normal instance pins? There are a couple of different ways to do hierarchy. If you use source= to associate the symbol to its subcircuit, you use the symbols in the io library to make your connections in the subcircuit schematic. In this case, the netlister expands all hierarchy automatically, making a flat netlist. On the other hand, if you use the model-name= attribute to make the association, you need to use the spice-subcircuit-IO symbols in the subcircuit schematic. In this case, you won't get a flat netlist, but if you also use the file= attribute you'll get a nested hierarchical netlist, which I don't find terribly useful. I would prefer using source= attribute. As I mentioned in the other thread I like this concept (except for current library search strategy). Also, I would like standard (BTW, are they in/out or input/output?) pins instead of that spice specific pins. One of the difficulties is that SPICE pin associations are by pin order (pinseq=), not by name. If you're importing a macromodel or cell from outside the gEDA world, you won't even have a subcircuit schematic. All EDA tools I know use pin numbering just for the sake of interfencing with external files (spice/verilog/vhdl netlist etc.). Often this pin numbering can be automatically retrieved from the netlist. This, in most cases, is not an issue if a schematic view is available. It would be nice to be able to suppress the automatic netlist flattening that gnetlist does, giving the back end the option of creating a hierarchical netlist in the source= case. I agree. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Multiple user libraries, parametrized components
Hi, There is a notion of a current library in gEDA (the one that can be set with: (component-library dir-name) (source-library dir-name) ). Now, what if I have multiple (sourcecomponent) libraries that I want to use? How to add them all so that they are visible in gschem? And how to select a cell A from library B instead of library C? source attribute seems to specify the file name only, without library name, directory etc. --- Also, is it possible to refer to an actual cell name / library name etc. from the symbol? Example: gTAG-consio.sym symbol has a label with a cell name included. This label, however, will not be automatically updated if I copy the cell to a different file. Is it possible to add some kind of an attribute, possibly a scheme code, that will return the current cell name (or other information)? Say, somebody might want to include a label containing: (cell-name), or (lib-name), or (revision-number), etc. Although, I agree, there might be a security risk in doing this when the cell is downloaded from unknown source, there are at least 2 ways of tackling this: 1. define a set of functions that can be called from the code embedded in the symbol. 2. provide a configuration option that by default disables evaluation of the code embedded in user-defined cells. 2a. prompt for a permission to evaluate such a code. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Symbol sizes
Why all symbols geda is shipped with are so huge? For example, an NMOS4 symbol in an asic library is 16mm wide and 26mm high when printed without scaling. I can force a scaling factor by using a different title frame (e.g. A2 instead of A4), or by not using frames at all. But: - this is a hack, - all attributes and annotations soon become unreadable. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: a project documentation system
On Jan 19, 2008 2:21 PM, Levente [EMAIL PROTECTED] wrote: On Sat, 19 Jan 2008 13:53:26 + Peter Clifton [EMAIL PROTECTED] wrote: I tried with telnet, but can't remember enough raw HTTP to work out what content type it is serving as. I don't think its emitting a Content-Type: ... header on GET. telnet logonex.eu 80 Trying 89.147.110.201... Connected to logonex.eu. Escape character is '^]'. GET /cgi-bin/viewvc/viewvc.cgi/lightsym/pmos.sym?view=co HTTP/1.0 HTTP/1.1 200 OK Date: Sat, 19 Jan 2008 14:29:22 GMT Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8+etch7 Expires: Sat, 19 Jan 2008 14:39:23 GMT Cache-Control: max-age=600 ETag: 32 Connection: close Content-Type: text/plain v 20070818 1 T 300 900 5 10 0 0 0 0 1 device=PMOS_TRANSISTOR [...] Connection closed by foreign host. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple user libraries, parametrized components
On Jan 19, 2008 6:35 PM, John Griessen [EMAIL PROTECTED] wrote: a r wrote: [jg] Library search path is a good concept for dealing with this. Proven in chip design setting to be low enough hassle, flexible. Can you tell me how to set this path? That's what I'm looking for. [jg]It's just a concept so far -- not implemented. OK. Also, is it possible to refer to an actual cell name / library name etc. from the symbol? [jg]Sounds too complex, labor intensive. How component name conflicts are resolved then? First one found wins. If it was done yet. One very typical use pattern is to copy whole library to another place (for backup, for reference for later changes). Without an explicit cell/library names this is asking for trouble. I understand that using explicit library names can be labour intensive (e.g. every time a cell/library is copied to another location its references need to be updated). How about a configuration editor then? A tool that can override library search order, or even permit explicit setting this time take this cell from lib_B not from lib_A. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple user libraries, parametrized components
On Jan 19, 2008 7:53 PM, a r [EMAIL PROTECTED] wrote: On Jan 19, 2008 6:35 PM, John Griessen [EMAIL PROTECTED] wrote: a r wrote: [jg] Library search path is a good concept for dealing with this. Proven in chip design setting to be low enough hassle, flexible. Can you tell me how to set this path? That's what I'm looking for. [jg]It's just a concept so far -- not implemented. OK. Also, is it possible to refer to an actual cell name / library name etc. from the symbol? [jg]Sounds too complex, labor intensive. How component name conflicts are resolved then? First one found wins. If it was done yet. One very typical use pattern is to copy whole library to another place (for backup, for reference for later changes). Without an explicit cell/library names this is asking for trouble. I understand that using explicit library names can be labour intensive (e.g. every time a cell/library is copied to another location its references need to be updated). How about a configuration editor then? A tool that can override library search order, or even permit explicit setting this time take this cell from lib_B not from lib_A. After thinking about this concept a bit more I came up with some more ideas: 1. Library search path, or rather some kind of a project file that contains a list of libraries, is a good idea. 2. Component browser (and file open dialog) should display all defined libraries and all cells from these libraries should be accessible. 3. Cell name conflicts should be resolved by: a) searching in the current library (i.e. one that contains a referencing/parent cell), b) if (a) fails, by searching in other libraries in the order defined in the library search path or a project configuration file. Why not a simple library search path and why not explicit library names? It is very often necessary to compare/edit same cell from two different libraries (say, a different version, or a library that someone else was working on). However, I agree that using explicit library names in 90% of use patters would be an overkill and would require additional tools/procedures (like renaming instances in copied or moved library). Also, I would rather avoid using separate scripts that make links in the project area. This is going to be hard to maintain and does not really do anything that couldn't have been done by a modification of gschem/gnetlist itself. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release (a r)
Hi Al, I have read all the comments and, sadly, they were mostly as I expected. The reason why I have drifted toward this topic is that I hoped you would be interested in needs of ASIC industry engineers, so you could improve some of gschem characteristics and make it more popular in this environment. From this discussion, however, I have got an impression that you are trying to teach all ASIC engineers how to use EDA tools your way, rather than to listen to their needs. Nevertheless, it is all your software and you decide where you want to take it. Again, what I would like gschem to have is: - a coherent design database, preferably with an API for a script language (scheme is fine), - parametrized device symbols ready to use with typical ASIC flows, - strong support for hierarchical designs, - responsive UI (retained-mode canvas etc), - sane defaults (autonumbering instances etc) What I don't care about (and preferably I would like not to be exposed to when using ASIC flow) is: - all the PCB related features, - multi-page schematics and slotted device, - inherited connections, global groundssupplies, Finally, I consider gschem a fine program, assuming your target users are component-level electronics designers in an academia environment or electronics geeks. For industry, gschem lacks features. For mainstream PCB designers, it has too steep learning curve. Regards, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release (a r)
Last question (out of curiosity).. when you experienced page redraw times near a second.. did you by chance happen to be running a compositing window manager like Compiz or Beryl? I am not 100% sure but that could be the case. I no longer have working compiz setup so I can't check it against a new gschem version. If so, forthcoming gEDA release should address that particular bug, with a moderately re-architectured drawing model. (Just FYI). I will have a look. Thanks, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release (a r)
On Jan 9, 2008 5:49 PM, Peter Clifton [EMAIL PROTECTED] wrote: - responsive UI (retained-mode canvas etc), Did seem a little odd to me. We have a canvas (ok, we don't call it that, but it is). OK, I have assumed that gschem is rendering everything in a paint event because of perceived slow redraw. And by definition, the rendering model of a canvas is retained. You put objects on it, they stay. (As opposed to a painting API where we draw things continuously, and have to repaint when windows cover regions and then become exposed again. Well, yes. If there is a scene there is a canvas. There is still plenty of possible opimisations that can be applied to it, though. Spatial index with grouping (and caching), layers and distance metric for filtering out small objects, to name a few. Sure, nobody is going to put millions of transistors on a single schematic page but gschem should be able to efficiently draw schematics with several hundreds of instances on a single page (eg. extracted netlists). -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: My trolling, gerbv, gattrib
:-) On Jan 9, 2008 6:07 PM, Peter Clifton [EMAIL PROTECTED] wrote: I did have to resist the temptation to tell him this was all impossible / unrealistic. That's exactly my point from the beginning of that discussion. Technically it is not a problem, in many points ASIC flow is even simpler than the PCB one. The problem lays rather in attitudes of many of you and in your views on how gschem should work. I had an impression, that if I had to develop gschem by myself it would be much easier to fork the whole thing out or even start from scratch that to go through all this politics. OK, let's not start another thread. EOT. Cheers, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release (a r)
Well, you can track a critical path using a raw netlist only, if you like. Besides, hundred of instances on a single schematic is nothing unusual - we are, after all, talking about the editor that does not make hierarchical designs easy. Let's cut this discussion short. It does not lead to any conclusion. -r. On Jan 9, 2008 6:47 PM, John Doty [EMAIL PROTECTED] wrote: On Jan 9, 2008, at 11:23 AM, a r wrote: gschem should be able to efficiently draw schematics with several hundreds of instances on a single page (eg. extracted netlists). Why should gschem be able to efficiently draw a humanly incomprehensible view of the circuit? John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [EMAIL PROTECTED] ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release (a r)
On Jan 9, 2008 6:43 PM, Peter Clifton [EMAIL PROTECTED] wrote: OK, I have assumed that gschem is rendering everything in a paint event because of perceived slow redraw. It kindof was.. it blitted from a back-buffer. (Which it still does). Many redraws would update the backbuffer and the main screen at once, line by line (causing a re-compositing each time). The fix made for 1.3.0 and beyond was to ONLY update the backbuffer, and invalidates the main screen buffer. The screen update is deferred until the app hits idle, and blits the whole schematic in one go. I have checked gschem 1.3.0. The rendering is, in fact, very fast now. There is still some noticeable delay when the scene/backbuffer is being updated, but the perceived speed is far better than when I tried gschem last time. -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release
On Jan 7, 2008 9:19 PM, Peter Clifton [EMAIL PROTECTED] wrote: On Mon, 2008-01-07 at 21:27 +0100, Dimitri Princen wrote: Here it doesn't start, it really looked like an ideal replacement for gwave. Not to be taken as preference either way, but in case you didn't notice, there was a pure C gwave clone announced earlier: http://herveq.free.fr/linux/gaw.php Thank you. Somehow I have missed this announcement. Gaw looks promising. Again, some usability features are missing (keyboard shortcuts, saverestore, calculator). BTW, there was also an awave tool announced here. Is this project alive? Cheers, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release (a r)
Hi, On Jan 7, 2008 8:15 PM, KURT PETERS [EMAIL PROTECTED] wrote: 1. I don't use gui tool for configuring simulation runs. Is there a way to start KJWaves directly in the raw file (or gnucap file) viewer mode? P- I don't use GnuCap, so I don't know what that mode is. I am not sure what you mean. I meant waveform viewer mode of the KJWaves itself. A mode in which only the waveform viewer window is visible. Preferebly, KJWaves could also accept result or save file names as command line arguments. P- have you tried using Analog analysis components in Gschem? It works for me. I had to do quite a bit of trial and error first and create a few of my own Gschem symbols... Well, last time I tried gschem it didn't work for me. It had no hierarchical circuit support, no ready to use components, no auto-numbered instances. It was slow to redraw and its wire editing mode was only slightly better than drawing them in a general purpose vector graphics editor. 2. vertical stacking of waveform panels P- What does this mean? Do you want the tabs along the left and right side instead of along the bottom? Which side do you prefer? Sorry, I meant panels as waveform graphs stacked one over another (instead of overlaying them as it is now or rendering to a separate tab) with separately adjusted Y-axis scales. This is a very basic function of all waveform viewers. 3. keyboard shortcuts in waveform viewer P- For what, in particular? At least all kinds of zooming and panning. Preferably with a zoom stack as well (so you can return to the previous zoom settings). In general, there are never too many keyboard shortcuts. 4. Two cursor and numerical readouts (X, Y, delta, frequency and gradient). P- That will be tough - you already get a cursor position readout by double-clicking on the graph (see below). Doing differentials would take some thought for implementation -- probably need some kind of dragging motion recognition. Other tools usually have two cursors activated with a left and middle mouse button. 5. savingrestoring the waveform view configuration. P- Interesting. would have to think about this. What, in particular, do you need loaded/saved? Everything. ;-) Ideally I could start KJWaves with a save file name as an argument and it would restore the view of all waveforms just as they were when I saved them. 6. better calculator and its interface (entering formulas by hand would do fine and treating them as regular waveforms) P- I thought about formulas by hand, but that requires a lot of error checking for fumble fingers. I really didn't want to go through that pain. That's very important functionality. Simple arithmetic functions are good for start but soon you would like to perform more advanced operations (slicing, eye-diagram, filtering, A2DD2A conversion). In a long term an embedded scripting is necessary. 7. there is a number of operations that result in exceptions being thrown (I will try to collect some representative logs and send them to you later) P- PLEASE do! OK, hopefully on Thursday I'll have some time to spend on this. 8. please, remove that big knob from the waveform viewer (what is it for, btw?) P- The big knob is a great feature (it doesn't print nor get included in a saved image (PNG)). It is used to specify where the data point is annotated (in what direction the arrow points). For instance, let's say you want point [3,4] to be placed at the upper right instead of below it's location on the graph. You would rotate the knob to point to the lower left, and then double-click on the graph at the location for point [3,4]. Give it a try, and then, if you have a better thought on how to place the annotations I will try to implement that instead. I probably should have put that relatively new feature on the tutorial, but I thought it was obvious?! :-0 I see. Nice function in fact. Still, I would rather put this knob in an annotation tool options dialog. Cheers, -r. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWaves - new release
Hi Kurt, Good piece of work. Thanks. I have several comments/fearure requests. They may not be useful in general case as the are mostly related to my use patterns. 1. I don't use gui tool for configuring simulation runs. Is there a way to start KJWaves directly in the raw file (or gnucap file) viewer mode? 1a. (just an explanation) For productivity reasons, I usually enter simulation testbenches in a text editor and in this file I include all the necessary model libraries, generated or extracted netlists etc. In case of OS tools I end up entering everything by hand as there are no good schematic editors available (pun intended). 2. vertical stacking of waveform panels 3. keyboard shortcuts in waveform viewer 4. Two cursor and numerical readouts (X, Y, delta, frequency and gradient). 5. savingrestoring the waveform view configuration. 6. better calculator and its interface (entering formulas by hand would do fine and treating them as regular waveforms) 7. there is a number of operations that result in exceptions being thrown (I will try to collect some representative logs and send them to you later) 8. please, remove that big knob from the waveform viewer (what is it for, btw?) The speed (interface only, I haven't tested kjwaves with big waveform files yet) is very good. Installation was flawless - this is a big advantage over gwave. Calculator, although rough around edges, has already proven to be useful. If you could at least resolve points 35 that would make kjwaves useful for my everyday work. Cheers, -r. On Dec 31, 2007 6:57 PM, KURT PETERS [EMAIL PROTECTED] wrote: I've just released a new version of KJWaves (available on sourceforge.net). It has the ability to read GnuCap files (requested by Al Davis) and a fix to the way log plots are displayed. Kurt Peters - Developer ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Problem with OGD1: Can anyone advise on good low-jitter
Random ideas: try better supply decoupling or package, stop other FPGA outputs when the clock generator is active (or at least put them far from the generator outputs). Check PCB - especially for return current paths of noisy signals. -r. On Nov 28, 2007 7:09 PM, Timothy Normand Miller [EMAIL PROTECTED] wrote: Sorry about the cross-post. We're -- THIS close to getting OGD1 done, with artwork in the hands of board makers who are working on quotes, and we've discovered a problem that could make the video output unacceptable. We've discovered that the clock generators in the Xilinx FPGA part are lousy for generating video clocks. We're seeing like 900ps of jitter, which causes artifacts on DVI monitors at resolutions as low as 1280x1024 when the cable gets beyond a certain length. (I don't recall all the details.) One option is to use the clock generators in the Lattice part, but even they have like 400ps of jitter, and they also severely limit the range of frequencies we can generate. So the best solution we can come up with is to put on some external clock generators. One for each video head. Problems: (1) more time to mod the design, (2) up to $15 each for the generators, (3) we have no idea what generators to use, how good they are, how to wire them. Does anyone know anything about these? Do you have experience with specific high-frequency clock generators and know how they perform and what kind of jitter they produce? Unfortunately, it could take quite a long time for us to find suppliers of clock generators, get samples, wire them up and test them, etc., so we just need find out if someone out there already has the right answer or knows where to look for it. Thank you for your time! -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
