Re: gEDA-user: Speaker SPICE modeling with gschem and ng-spice/gnucap
On Monday 12 September 2011, Hannu Vuolasaho wrote: > Is it possible to do same thing? Input wav to simulator and > get speaker's output and hear it? I know it's not perfect > but it could be very helpful. Has someone done this before > and provide some hints, examples or links? If you can do some coding, you could write plugins for gnucap that could implement WAV in and out in a sense similar to what LTspice has. For WAV input, one way is to make a "bm" plugin, that would make a variant of the voltage source, or anything else, but that is beyond what you are asking for. It should be simple to read the WAV file and buffer it using the gnucap WAVE class. You could use "bm_pwl.cc" as a starting point. That is the plugin that provides Spice-style PWL. Look at the transmission line (d_trln.cc) as an example of the use of the WAVE class. For WAV output, make a new device, as a plugin. Start with the current source (d_cs.cc) .. strip out most of it, and use "tr_accept" to write out the WAV file. You would need to use a bit of trickery to write out fixed time steps from gnucap's variable steps. You could force the time steps, that's easy, but it would run very slow. This is just ideas .. seems fairly simple to me, but I haven't actually done it. Of course you could write programs to translate files, but I think the plugin approach should be easier, and it will certainly run faster. Generating a PWL for input is fairly universal, but the spice "raw" files are different for every version of spice. I am bewildered at why ngspice hasn't moved on to something more standard. Both ways, the text mode translations on every time step will certainly be slow, and could also lose some precision. That may even be slower than the calculations. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Reinventing the wheel
On Monday 16 May 2011, Steven Michalske wrote: > But lawyers can use that clause as a loophole to invalidate > legitimate patents. Minor side effect of "lawyers can use that clause as a loophole to invalidate ILLegitimate patents" ... which outnumber the ligitimate ones a million to one. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: zener diode modeling
On Monday 18 April 2011, yamazakir2 wrote: > Does anybody have a nice and simple zener diode model they > would like to share? The model that I am using has trouble > with convergence in context of a complicated switching > circuit with ngspice. have you tried gnucap? You will need the spice-diode plugin to get the reverse breakdown, or use the parallel combo that Andy suggested, because the "native" model doesn't do breakdown. Several plugins do. The two-diode and battery approach has an advantage that the iteration limiting is better behaved that way. The spice junction limiting doesn't work correctly for the breakdown region. The code isn't there. I don't expect the "B" device approach to help much if any. Usually its convergence characteristics are worse than the "C" models. The reason I expect gnucap might work better here is the time step control algorithm, which gives much tighter control than the algorithm used in Spice. In a later post, you said that the convergence failures are occuring during the transient analysis. It runs for a while then screws up. Spice time step control is based on three things .. 1. Truncation error in numerical differentiation, storage elements only. 2. Iteration count. 3. Pre-determined "break-points", but only in a few places. The problems: 1. Non-storage devices do not participate in step control, at all. In the simple case, it might not seem like a problem, you just get a plot that is rough to look at, and manually reduce the step size. In a complex case, the undersampled waveform provides a very wrong input to the storage devices, causing incorrect results. The familiar aliasing you get from sampling is one example of this. 2. No handling of analog events. 3. Using iteration count as step control involves many failure/recovery cycles. The failures are not completely forgotten, so numeric problems can drive it to neverland. Gnucap uses these methods as part of the algorithm, and where used they work the same, but also has more. 1. Non-storage devices also participate in step control, based on curve fitting. Step size is chosen such that common interpolation will produce a curve, where the whole curve is within an error bound. (Spectre method) 2. Some devices generate analog events, for example on a region change. At an analog event, the time of crossing is error controlled. Unfortunately not all devices do this, but you can add switches (S device) to specify places in the circuit where you need this extra control. 3. Behavioral devices, including spice-style sources (Sin, sffm, etc) generate analog events sufficient that they can be modeled correctly, including phase. Most of the time, you can skip specifying a time step entirely, and it will automatically step appropriately. In this case, if I understand correctly, you have a circuit that has some abrupt changes that occur at certain times, but before and after that time activitity is slow. With Spice time stepping, the steps will be large before the abrupt change, skipping over it. In some cases, it seems to work and you get believable wrong answers. In other cases, it results in a convergence failure, triggering a step rejection, and a retry with smaller time steps. The Gnucap algorithm helps in several ways .. First, since all components participate in time step control, it is likely that a shape change in the waveform will cause a reduction in step size, even if there are no storage devices. Often this is enough. In the future, the semiconductor devices will generate analog events on region crossings, but they don't yet. For now, you can do this explicitly by adding a switch to the circuit. Recall .. the voltage controlled switch has an input port, where crossing a threshold causes a resistance change on the output port. The trick here is to just use it to detect the crossing. Ground both output terminals, and connect the input across the critical spot, for example across your zener. Set the threshold (in the switch's .model statement) at the critical voltage. It Spice, this won't do anything. In Gnucap, if you use the Spice switch, it will work just like it does in Spice. You need to use the Gnucap native switch model. What it does is to force accurate time stepping around the crossing. There will be extra time steps just before and after the crossing, so as to provide additional accuracy in the region of the crossing. The additional steps are such that the accuracy of the time of crossing is error controlled to the specified tolerances. How it helps in this case, is that rather than going past the critical spot, then going into a recovery cycle, step size is reduced leading up to the crossing, so it doesn't go by, and doesn't need to fall back to the recovery cycle, hopefully solving the convergence problem. It's not perfect, there is still work to do, but I believe that as it is, it provides a signi
Re: gEDA-user: [spice] capacitor current
On Saturday 16 April 2011, Levente Kovacs wrote: > I want to simulate my low pass filters. So far, I managed to > have my theoretical results. > > Now I want to know the currents of the capacitors vs. the > frequency. > > I remember that the best way is to put 0V voltage sources in > series of the capacitors, but I don't know how to get the AC > current of the source. > > Could you provide any hint on this? With Gnucap, just ask for the capacitor current. print ac i(c*) (this prints all capacitor currents) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: nice C++ (was Re: pcb plugin smartdisperse fails on load)
On Friday 25 February 2011, Larry Doolittle wrote: > On Fri, Feb 25, 2011 at 12:32:13PM -0500, DJ Delorie wrote: > > > So, could you, pretty please, point me to some nice C++ > > > code. > > > > Sorry, the work I did back then was not OSS. I'll have to > > write some more "nice C++" for you :-) > > Tastes may vary, but some years ago when I went looking for a > clean C++ matrix math class library, I was favorably > impressed by newmat http://www.robertnz.net/nm_intro.htm > Operator overloading with a clear purpose! Gnucap is C++. There is a matrix class using templates. It is an advanced sparse solver specially designed for "fast-spice" simulation. For now, Gnucap only uses it for types double and complex, but it works for any type that defines the standard operators. I have used it for symbolic polynomials, but have not released the code yet. There is also a plugin system that really works. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
> On Fri, 2011-01-14 at 21:14 -0500, al davis wrote: > > I don't know where that is done, or if it is done > > in a form that would be useful here, or whether there > > exists the code to go the other way (generate a schematic > > given a netlist and rendering info) which is equally > > needed. On Saturday 15 January 2011, Peter Clifton wrote: > Not done. Would be nice though - but I'd rate it of similar > complexity to a board auto-router. (Not as rigidly > constrained topologically, but to do well would require a > decent auto-place, and a decent auto-router - even if the > rules are different to that used with a PCB). Ah .. but I said "and rendering info". Generating a schematic from a netlist without the rendering info, you are absolutely correct. But that's where the "rendering info" comes in. It tells where to place and route in a portable way. Where does the rendering info come from? Mostly, it would be saved when you convert a schematic to a netlist. That way it is available when you convert it back, so when you make a round trip you get the same schematic you had before. Or, if you made some changes in the netlist you get the schematic with the changes. You might need to move the new stuff for looks, but it would at least be functional. Or, convert one kind of schematic, saving the rendering info in a portable way, and write it out as another kind of schematic. That's the translation facility. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Monday 17 January 2011, Stephan Boettcher wrote: > al davis writes: > > How about prefixing simulation attributes with a dot. > > No, please, use a proper namespace prefix, like > > spice- verilog- sim- > spice: verilog: sim: > > Backend namespaces, use namespaces, with fallbacks into > legacy and global namespaces. > > spice-value= > sim-value= > value= If it was just the file, I would agree. That was my first thought. In this case, that means the schematic itself would be visually cluttered with repetitions of the namespace prefix, unless there are changes to gschem. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
On Monday 17 January 2011, John Doty wrote: > I'm unhappy with tuning gschem/gnetlist to be especially > friendly to any specific downstream flow. Al's favorite > downstream tool is apparently Verilog, so that seems to be > what he wants to target, with every other flow having to > adapt. I'm unhappy with tuning gschem/gnetlist to be especially friendly to any specific downstream flow. John's favorite downstream tool is apparently SPICE, so that seems to be what he wants to target, with every other flow having to adapt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: multiple attributes
It's well past time to realize that there is more to simulation than Spice. A schematic should be able to be used with a variety of simulators, and the netlister should take care of the differences. Symbols should not have anything specific to any output format. This is difficult considering how irregular the Spice format is, but hacking the symbols to compensate for shortcomings in one output format is short sighted, especially a format where the inventer of the format wishes it would be replaced by something cleaner. In a schematic, attributes really need to have a type. There are simulation attributes, layout attributes, etc. To minimize the changes to code, for now let's identify the type of an attribute by a non-alnum first character. How about prefixing simulation attributes with a dot. A Verilog netlister would just emit the attributes marked as simulation attributes in the appropriate format, regardless of the meaning of a symbol. A Spice netlister could do this in some cases, but needs extra code to handle special cases. So, for a mosfet, you have attributes like "l" and "w". These must not be hard coded, because it cannot be known in general what attributes will be used. A resistor would have an attribute "r", a capacitor would have an attribute "c". Again, not hard coded but rather just by convention. A Verilog netlister might output: nmos1#(.l(1u), .w(1u)) m12 (.d(3),.s(4),.g(9),.b(0)); resistor #(.r(10k)) r33 (.n(3), .p(8)); boxoid #(.hat(10),.foot(.01)) xbox1 (.top(3), .bot(7)); A Spice netlister might output: m12 (3 9 4 0) nmos1 l=1u w=1u r33 (8 3)10k xbox1 (3 7) boxoid hat=100 foot=.01 For the Verilog netlister, no funny business is needed. All instances have the same syntax. All attributes and connections are mapped by name. It's easy. For the Spice netlister, there are some issues. In general, the attributes can be passed by just stripping the dot and copying, but that doesn't work for the resistor. Different types have different syntax. This must be determined from the type by the netlister. In this case, the mosfet and subckt call can use the same syntax. They are not special. This behavior can be thought of as the default behavior. The resistor is a special case. One particular attribute "r" needs to be emitted without its name. This is a netlister task, not part of a symbol. This is where some kind of mapping is needed. The resistor isn't the only special case. Spice is seriously burdened with those special cases, which is why a spice netlister is so complicated. Still, it is a netlister problem, not a symbol problem. Let the symbols be consistent, and the spice netlister support the bugs in spice. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Sunday 16 January 2011, John Griessen wrote: > On 01/15/2011 10:36 PM, al davis wrote: > > Unless I massively missed something, verilog is completely > > procedural. > > Really verilog is all in parallel, not procedural code, > unless you want to put some in with special features that > are trickier to use than everyday verilog. > > The basic statement of verilog is assign, which defines wires > and connectivity of busses of wires and renamings and logical > combinations of wire values... Much like a graphical > schematic. > > Modules also map names in verilog, allowing reuse of subcells > with different names for wires inside them. You are thinking of the original Verilog, as it was in its first draft from Cadence over 20 years ago. Today, Verilog means a family of languages with common syntax that do just about everything in electronics. There is System Verilog, Verilog-A, Verilog-AMS, The insiders refer to the old digital verilog alone as "Verilog-D". If simulation means Spice to you, you are 20 years behind. If Verilog means only digital to you, you are 20 years behind. Are we proud of being 20 years behind? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Saturday 15 January 2011, Kai-Martin Knaak wrote: > I don't see how this could possibly work. Both, gschem and > altium contain a graphical representation of the circuit. > Unless I massively missed something, verilog is completely > procedural. Graphics information would be lost during the > process. Yes .. you missed something. Verilog has a structural part too, which is well documented, has a published standard, and completely adequate for this. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Saturday 15 January 2011, Kai-Martin Knaak wrote: > I looked at lang_verilog_in.cc > Unfortunately, my c++ is not fluent enough to read the code > right away. This is aggravated by the lack of comments on > what the various code blocks do. Since I also don't know > verilog by heart, the whole file looks more like a puzzle. > Sorry, but this fruit is hanging too high for me. (You can > call me programming coward) > Is there a comprehensive specification, what gnucap expects > to get from the import plugin? If so, it might make a > gschem import component a lot easier. I started to write up things like that: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:tech:plugins but then other things came up so I didn't have time to do more. If somebody actually wants to help, wants to write a language plugin, I will work with you and complete the documentation. The interaction is a necessary part of completing the work. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
> On Jan 14, 2011, at 6:32 AM, Peter Clifton wrote: > > Ideally (to be forward compatible with format changes), > > that plugin would use libgeda. If someone starts on this, > > please let us know via the lists + bug tracker ( > > https://launchpad.net/geda/+bugs ) if you find any API > > which is lacking. > On Friday 14 January 2011, John Doty wrote: > The trouble with this reasoning is that the .sch file format > is reasonably simple, well documented, expressive, > extensible, and stable. The libgeda API is complex, poorly > documented, and badly in need of revision. Only a few tools > use the libgeda API, but there are many useful scripts out > in the gEDA universe that deal with .sch and .sym files > directly, so file format changes would be big trouble in any > case. You have a point ... Without getting into the quality of the format or libgeda, lets assume that both are likely to change in the future in some way. The Gnucap plugin system allows many plugins for many different formats. It is reasonable to expect that when the format changes there could be plugins for both the new and old versions, providing a migration path between them. If libgeda changes, which it will need to if it will support the new format or new features that may be needed, any code using it also needs to change, causing maintenance issues. If something is written, it is not known whether whoever writes it will want to make the changes as libgeda changes. Besides, it may be necessary to keep the old one around for backward compatibility. It is better to eliminate such a burden. Reading a file is easy. The hard part about the geda format, where use of libgeda may be advantageous, is establishing connectivity. I don't know where that is done, or if it is done in a form that would be useful here, or whether there exists the code to go the other way (generate a schematic given a netlist and rendering info) which is equally needed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FYI [Fwd: [Balloon] Balloon 4]
On Friday 14 January 2011, Kai-Martin Knaak wrote: > Peter Clifton wrote: No. David Bisset wrote, on another list. Peter just passed it on to us. > >> It is intended that these will be published in Altium > >> format as that is the CAD package of choice for the > >> design process. > > Why not geda in the first place? Anyone here who uses LTspice need only to look in the mirror to figure that out. Apparently, there are some features that Altium has that they consider to be important. What are they? > >> However we will also explore the possibility of publishing > >> the files for one of the Open ECAD packages such as gEDA. > > How would the conversion be performed? That's obvious. They are waiting for us to provide a conversion utility. Let me ask for help again. .. Gnucap has a conversion facility based on Verilog syntax. If someone writes a plugin for geda format (which I have already asked for), and someone else writes one for Altium format, we have that translator. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
On Friday 14 January 2011, Peter Clifton wrote: > On Thu, 2011-01-13 at 19:41 -0500, al davis wrote: > > > On Jan 12, 2011, at 11:29 AM, al davis wrote: > > That's great. There is a long list of things that need to > > be done. Where do you want to start? > > > > > > > > My preference is to start with netlist translation, using > > gnucap's translator system that goes both ways. In this > > case, that's a "language plugin", reading and writing the > > gschem format > > Ideally (to be forward compatible with format changes), that > plugin would use libgeda. If someone starts on this, please > let us know via the lists + bug tracker ( > https://launchpad.net/geda/+bugs ) if you find any API which > is lacking. That makes sense to me, I think. > > then another language plugin for the PCB format. > > I don't see how the two are congruent. Did you mean for > extracting layout for simulation? Yes. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
> On Jan 12, 2011, at 11:29 AM, al davis wrote: > > Both of these are areas where we could take the lead, but I > > need help to do that. I can't do it alone, and can't do > > it if people are fighting it. Does anyone want to help? On Wednesday 12 January 2011, Edward Hennessy wrote: > I would like to help with this project. That's great. There is a long list of things that need to be done. Where do you want to start? My preference is to start with netlist translation, using gnucap's translator system that goes both ways. In this case, that's a "language plugin", reading and writing the gschem format, then another language plugin for the PCB format. al. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Soft and Hard symbols
> Dietmar Schmunkamp wrote: > > Start a design with gschem --> simulate it --> get it thru > > pcb --> extract physical paramaters from the layout --> > > OPTIMIZE* --> feedback to gschem --> restart the loop. On Friday 07 January 2011, Kai-Martin Knaak wrote: > Unfortunately, at the current state of geda and friends the > simulate step is a weak spot. Not so much because of > weaknesses in the simulation algorithm. With gnucap and > ngspice there are two very capable engines. It is the > absence of readily available models and almost no GUI > support that blocks the road. Actually, not at all because of weaknesses in the simulation algorithm. NGspice has essentially the same algorithms as LTspice. When I benchmarked them (a few years ago) they were indistinguishable, which makes sense because they are both derivatives of Spice-3 from Berkeley, which also is mostly indistinguishable in a performance sense. Gnucap has more advanced algorithms. My benchmarks show much faster performance on large circuits and more robust time step control. Ironically, "switch mode power supply" is a type of circuit that works fine on gnucap, but I got identical believable bad results on both NG and LT spice, due to step control problems. There is a real problem with the interface to gEDA, and also with displaying the results. Does anyone want to help fix this problem There is somewhat of a problem with models, because most models are written for a specific simulator and moving to another makes a lot of them not work. There are several strategies for improving this situation, ranging from adding features to the simulator to porting models. Both of these are areas where we could take the lead, but I need help to do that. I can't do it alone, and can't do it if people are fighting it. Does anyone want to help? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: series of gnetlist backend patches
On Monday 03 January 2011, Dan White wrote: > The Analog Rails tweaks to gnucap make parallel simulations > with hspice feasible from a common *.sch set. Their repo is > at > http://redmine.gnucapplus.org/ I could use some help with gnucap development. I have asked Analog Rails to officially participate in the main line of gnucap development, but they refuse. Management decision. Very bad management decision. In the geda context Gnucap's preferred netlist format is Verilog, but the geda Verilog netlister doesn't do attributes and other problems, so it is useless for this. The spice format has been a serious headache for simulator developers for years. Taking this a step further. There is a need to treat nets as first class objects, which no geda netlister does. Gnucap has its own translation facility, that can import as well as export. If someone can write plugins for gschem format, and PCB format, that would be most appreciated. Gnucap was never intended to be just another spice, but rather a modern replacement. It's the original "fast-spice", and the first true single kernel mixed-mode simulator. I could help on the research side too, but in this context, just someone to grab the low-hanging-fruit would be extremely helpful. Everything that any Spice has that Gnucap doesn't is low-hanging fruit. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Resistor values…
On Saturday 25 December 2010, Vanessa Ezekowitz wrote: > * If the part in question can usually be described by a > single value, for the purposes of the signal flow in the > schematic that is, then give it a default of "value=0". No. Zero is almost always wrong. The only sensible default value in this case is a copy of the reference designator. If the reference designator is "R1", the default value should be "R1". Justification ... For simulation, all modern simulators, and some not-so-modern simulators have a means of assigning values to parameters. In a spice format, you could say: .param R1=10k or something like that. Some let you use parameters in other ways, making it even more useful. > * If it is a discrete part that is specified entirely by its > part number rather than a measurement, like a diode or a > transistor, then pick a reasonable default; "value=1N914" or > "value=2N". As I recall, those are specific devices that were popular 40 years ago. Not sure how relevant they are today. Unless you link to something, they are just arbitrary strings, no better than any other. The best default would be something that is more universally meaningful, and not specificm like "D" or "diode" for a diode, or "NPN" for an NPN transistor. For a simulator that reads spice format, you could then say: .model D D .model NPN NPN to make the names meaningful. It might be useful to make an "include" file to define these things. > * If the part is something like a logic IC, use the standard > name of the part in the fastest commonly available series > for that particular gate; "value=74F74" or "value=74HCT245". Same as diodes. Names like 74F74 have no meaning, unless you look it up, and are completely wrong most of the time. > * If none of these fits, then leave the "value=" attribute > off entirely, since the user would have no choice but to get > creative anyway. > > The point here is that every one of the component types in > question has a value, therefore the "value=" field will end > up being utilized by nearly everyone who instantiates the > symbol for that component. Otherwise, schematics with a lot > of such symbols become nearly impossible to read, let alone > debug. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Hierarchy Refdes and Component Values
On Friday 17 December 2010, Thomas D. Dean wrote: > I have a schematic with seven instances of a schematic, a > hierarchy. > > I want to give different values to the resistors in each of > the sub-circuits. > > For example, I have S1 thru S7. In S1, I want R1=100, in S2, > I want R1=1k, etc. > > Is this possible with hierarchy? With Gnucap, just give the resistor value a name, and pass it in when you instantiate the subckt. .subckt thing (a b) R1 (a b) dv .ends X1 (1 2) thing dv=100 X2 (3 4) thing dv=1k It is better to let the simulator handle hierarchy. The netlister should NOT expand subckts. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FUNDING
On Wednesday 15 December 2010, Michael Sokolov wrote: > ... by way of standard open source mailing list managers > detecting and automatically rejecting posts encoded in > base64. Just because Eudora on Windows can't cope with it? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: FUNDING
On Wednesday 15 December 2010, timecop wrote: > Funny you mention that, this email reads perfectly fine in my > closed-source email reader. Of course it does. You are using the same closed-source email reader as Andrew does. Now, how about a different closed-source email reader, like the one Rick uses? By the way ... it reads fine on my open-source email reader. I use several different open-source readers. All of them have no problem with base64, including "mutt" which is purely text based. Base64 is a published standard that should be universally supported. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: TRACKERS [was: Re: gEDA-dev: Dev list [was: Random thoughts onthe future interface of PCB]]
On Friday 10 December 2010, kai-martin knaak wrote: > al davis wrote: > > In gnucap, I always give contributors top priority, but if > > a patch comes in without advance discussion, often there > > is something wrong with it. > > Well, my three trials to contribute were the opposite of > out-of-the-blue. All of them started with me talking about > the problem on the list. I announced, that I was working on > a fix and even asked, what format the patch should be. > Still, I had to do repeated nagging before I got feedback. I don't remember that. What I remember is that you made a statement, I responded, and it stopped there. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: TRACKERS [was: Re: gEDA-dev: Dev list [was: Random thoughts onthe future interface of PCB]]
On Thursday 09 December 2010, Stephen Ecob wrote: > We're hearing complaints that some submitted patches aren't > receiving enough attention, but there simply isn't enough > maintainer time available to give everyone as much attention > as they'd like. If submitted patches don't receive enough attention, maybe there is something wrong with them. Maybe they don't work, introduce bugs, don't come with adequate testing, mess up future plans, or something like that. In cases like this, the patches require lots of work by the project accepting them, maybe more than they are worth, or more than just doing it over. In gnucap, I always give contributors top priority, but if a patch comes in without advance discussion, often there is something wrong with it. If somebody contributes a new plugin, usually it is accepted immediately. We may have some discussion about it, but new plugins are accepted freely, and distributed as user contributed plugins. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: control verilog module parameter order when converting .sch and .sym with gnetlist?
On Sunday 21 November 2010, Paul Tan wrote: > Since most Verilog simulators (including Icarus Verilog) > support "EXPLICIT connection" method for the lower level > Module Instanciations, so it is not absolutely necessary > (although desirable) to match the Module portname order > with the Module instantiation portname order. I think it is safe to assume that ALL Verilog simulators support the explicit form. The explicit form is preferred. I don't see any practical way that the netlister can reliably support connection mapping strictly by order. It's a real pain in Spice. If someone is going to improve the Verilog netlister, there are other points that really do need to be addressed, such as passing parameters and net types other than "wire". Gnucap needs them. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Ben mode feature request
On Sunday 31 October 2010, Stefan Salewski wrote: > Can you please explain why we will always need the command > line for simulation in gEDA? (I have newer found the time > doing simulations...) Try this without a command line: Experimentally finding model parameters: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:experimentally_finding_model_parameters Distortion analysis of an oscillator: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:phase_shift_oscillator Bandwidth analysis of an FM transmitter: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:examples:fm_spectrum_analysis You should be able to do basic stuff without a command line, but outgrow it by your senior year in college. Most GUI's lead you into a trap. We need a GUI that teaches you to move on. We don't have it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Sunday 24 October 2010, c...@eugeneweb.com wrote: > I sapose that you could pass an argument to gnet-spice-sdb > (or set a variable) to clue it in on which spice variant to > target. You could go nuts with that. The only real standard in spice is back in the spice-2 days. Then they all evolved incompatibly from there. All simulators using spice format do at least something to read files made for another, but none are perfect. On the high end, it seems that Hspice is most accepted as a pseudo-standard. On the low end, it seems that Pspice is most accepted. That's two, both spice-2 forks. Then there is a third, for the spice-3 forks that the minor players are more likely to follow. > In the long term maybe an XML like standard language would be > a way to modernize it. In the long term, most people in the know prefer a Verilog format for netlists. The format is well defined, with an official document. Most high end simulators support it to some degree, but do not default to it. NO low end simulators support it. They are all followers, and waiting for someone else to be first, then they will be forced to support it. Gnucap supports it, gEDA does not. Still, that doesn't help with legacy models, which come in many different formats, and have lots of issues other than syntax. > Either way I think it might be better to put the parameters > in another attribute like say, params so that value is not > overloaded and you can choose to handle them differently if > you like. Eg, I would like to keep someting like 10k in > value just to keep the schematic looking clean. Something needs to be done. The problem has been known for years. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Newbie wondering about simulation
On Sunday 24 October 2010, Hannu Vuolasaho wrote: > Changing manually to X1 makes the simulation work but it > isn't really the Solution. Yes, it is the solution, for now. Ultimately, the solution is to move away from Spice format netlists. In Spice, the device type is determined by the first letter. The letter "M" says to use a built-in MOSFET model. The name (after the nodes) refers to a ".model" "card". (When using a spice netlist, it is common to refer to the lines in a netlist as "cards") The letter "M" does not ever refer to a "subckt". If something is defined as a subckt, the first letter of the label must be "X". ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Sunday 24 October 2010, c...@eugeneweb.com wrote:
> and have gnetlist spit out a line like this:
>
> XU3 10 9 0 POT VALUE=10k SET=0.5
>
> and pot.mod could be something like:
>
> .SUBCKT POT 1 T 2 PARAMS: VALUE=1K SET=0.5
> RT 1 T {0.999 * VALUE * (1-SET) + 0.0005 * VALUE}
> RB T 2 {0.999 * VALUE * SET + 0.0005 * VALUE}
> .ENDS
>
> I've googled hither and yon, looked at gnet-spice-sdb.scm but
> couldn't find anything definitive. Is there some other
> attribute that you might put a list of parameters in?
The situation is less than ideal, but workable. When netlisting
to a spice format, the "value" attribute contains a string which
is copied directly.
So, for XU3, you should set the "value" to the string
"VALUE=10k SET=0.5" .
What is less than ideal is that you must use the simulator's
syntax there, which means you may need a different schematic for
different simulators. This is workable with variants of the
spice format, but unworkable for non-spice formats. For
example, the Verilog netlister does not do attributes at all.
For example, of those using spice variants, the "PARAMS:"
keyword is required on some, optional on some, and illegal on
some. It is optional for gnucap (recent snapshots, it is
illegal for 0.35). As I recall, it is required for Pspice,
illegal for NGspice, but I could be wrong here, or it could have
changed recently. Regardless, when you make the schematic, it
is part of the "value" string.
Another syntax nuisance is that some simulators using spice
netlists use ticks ' ' instead of curly's to enclose an
expression. I believe Hspice uses ticks, Pspice uses curly's.
Gnucap takes either. I don't know what NGspice accepts.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very backward time step?
On Tuesday 21 September 2010, Rubén Gómez Antolí wrote: > Gnucap 2009.12 is so stable, why not released? > > (In several days, I think even ask at debian maintainer to > include snapshots, at least, in experimental branch of > Debian.) The problem is with the build system. I spent most of January working on just that, then there were other things that got in the way of any progress, including moving. Mid summer, I decided that stable release would come from New York, not from Michigan, in order to not delay the move or release something with problems. Again, 2009.12 code is sufficiently robust as to be ready. Problems are with the build system, as related to plugins. I'm in New York now, so things should get moving again soon. Debian (and several other distros) do include development branch releases of other projects. I had hoped they would here, but they haven't, even in Debian "unstable". Some distros have old development snapshots . FreeBSD has 2008.06.08, Mandriva has 20060830 (which is older than 0.35), NetBSD has 20060708 (older than 0.35). Only Gentoo has 2009.12.07. Meanwhile, I see snapshots of Gimp and others all the time. It is important to developers that the "unstable" distros DO package the development branch, to test it and provide feedback. Hamish and Chitlesh, how about it? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very backward time step?
On Tuesday 21 September 2010, Matthew Wilkins wrote: > It seems like the values that he gave (10m 10 1) could be > interpreted either way, but in the plot image it shows > about 15 data points between the times 4.9219 and > 5.0781. That seems to correspond to 10 ms times steps, no? Could be ... one of the reasons the spice format drives me crazy. Oh yeah .. If you have a 1 second time step, you can't have a sample at 10m, so 10m must be the time step, and it starts at 1 second. Decision made many years ago, and even I get confused by it sometimes. Such is the nature of Spice format extensions, but without them we would be stuck at 2g6, which was last updated about 25 years ago. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very backward time step?
On Tuesday 21 September 2010, Matthew Wilkins wrote: > You're specifying a 10 ms step size (first parameter in the > tran command), and it looks like that's what you're > getting. The period of a 60 Hz sine wave is 16.6 ms, so > you're getting fewer than 2 samples per cycle. Try changing > the step size to 1 ms and things should start to look > better. He's getting 1 second steps. Spice only takes two numbers for transient. He uses three, so it is Fortran order .. start stop step. The spice way of using a different order for each command confuses me, so Gnucap takes either spice order or Fortran order for everything. Gnucap has the ability to continue a transient analysis, which spice doesn't, so some things need to change. > In most simulations the solver would calculate additional > intermediate time steps which would show up with 'trace > all', but I'm guessing that your circuit model is so simple > and linear that the solver just calculated the values at the > requested time steps without creating any intermediate > points. In 0.35, (and Spice) this is true. In recent development versions, the step control is robust enough to figure this out regardless of what you specify. (well almost, but yes in this case) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very backward time step?
On Tuesday 21 September 2010, Chris Cole wrote: > I get a normal sine wave output, > but when the frequency increases, the wave changes > considerably and starts to turn into a triangle wave...I'm > not sure what I'm doing wrong, but this is strange. In the tran command (tran 10m 10 1) you asked it to strobe at 1 second intervals. So, no matter what the signal, you get samples 1 second apart. If you add "trace all" to the tran command you will see all of the samples, which should produce a smoother waveform. How it works is a throwback to when people actually looked at ASCII plots. It needs to change to make "trace all" the default, and have the strobe interval require a keyword "strobe" like spectre does. The actual time stepping is determined internally. There will be extra steps internally if needed to get a proper simulation, but they are not displayed unless you ask for them. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very backward time step?
On Friday 17 September 2010, Chris Cole wrote: > I'm trying to do a very simple power supply simulation with > gschem and I'm not getting very far. > I'm trying to do a bridge rectification of a 24 VAC supply to > DC current. I'm able to do a transient analysis for 10 > iterations before I get: > > very backward time step > convergence failure, reducing (itl4) > > I read somewhere that "very backward time step" is indicative > of a software bug. I'm sending my example schematic and > netlist and a sample script, sim.sh that I'm using to run > everything. As usual, John Doty is wrong. You should get a more recent version of gnucap. With 0.35, I had to make gmin=100u. With the latest, it worked fine as is. Gnucap time step control is usually more robust than Spice, especially with recent development snapshots, although sometimes Spice appears to work but gives wrong answers without warning, and on the same circuit Gnucap honestly admits failure. If I run from the .net file, and manually do the rest, it works fine for me, but add "trace all" to the transient command so you get all of the time steps. If I run from your .sh script, gnetlist clobbers the .net file, and the generated .net file has some problems .. no ground, a missing value ... That script doesn't work with recent snapshots, you must be using an old version. If you are simulating power supplies, remember that the defaults for things like GMIN are designed for small CMOS circuits, so you might need to change them. Your time step parameters (specified in Fortran order, not spice order, that's ok) don't make sense for this circuit. Showing a visible step size of .1 second will hide most of the info for a 60 Hz input. Assuming you want to hide that and look at the ringing of the LC filter, it's still too coarse. Recent versions of gnucap will figure out proper internal time stepping ok in spite of that error, but just show you samples at .1 second. Older versions may need some help to make sure the 60 Hz signal is accomodated with a .1 second visible step. This might be the problem you are seeing. If that is the case (and you are using an old version of gnucap) try adding the option "skip 100" to the transient command, which will force an internal time step 100x smaller than the printed time step. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, John Doty wrote: > Then go ahead and explain it in a single breath. And how does > this force you to hack the netlist? I don't want an argument. I want help making it better. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, John Doty wrote: > Exactly what is the problem you experience? 1. There are many components that do not netlist properly. Every symbol must netlist correctly, no exceptions. There is more to simulation than simple spice circuits. 2. There are others that netlist properly to spice only because of hacks specific to the symbol. It is not acceptable for the netlister to have any knowledge of any specific symbol or any specific parameter, ever. 3. There is no reverse translation. 4. In most cases, the user enters a value string, in whatever syntax the simulator wants, which means it could be different for different simulators. 5. It seems to be necessary to have a different schematic for layout and simulation. 6. Probes are not supported. 7. Nets are collapsed out, even if the simulator doesn't want it that way. 8. I'm tired of hearing about how perfect it is, when I know it isn't. 9. We need to support modern simulators, not just 30 year old antiques like Spice, and we need to support them fully, not just the compatibility subset. 10. geda seems to insist that everyone who wants to play here must adopt its way of doing things, which is in many ways like a proprietary system. We don't outreach to formats that the leaders consider to be standard. 11. That "two stage amplifier" example should be simple enough to explain in a single breath, but it's .. how long I could probably come up with another dozen, but this should be enough. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, kai-martin knaak wrote: > > You have said many times how much you love LTspice, > > No I did not. I said, that I use it because using gnucap or > ngspice with gschem is such a hassle. When I last looked into > it, it took me much more time to get results with > gschem/gnucap than with ltspice. And this is while schematic > capture with ltspice is a bitch by itself. "Much more time" > in this case translated to days rather than hours. I agree that it is a hassle. I have said it a few times. What gets me most is that the translation is incomplete. It seems I always need to hack the netlist. The Verilog format (which the development branch of Gnucap ordinarily prefers) really doesn't work. It doesn't do attributes at all. Without attributes, you can't (for example) set the value of a resistor. It has other problems too. Since Gnucap has its own translator system, I would like to see a plugin for it to read the gschem format directly. (and also one to read the PCB format). That would have the side effect of being able to import date to gschem. The same plugin could be used with gnucap's standalone translator, to provide file translations that could be used by other programs. > This is the minimum set of features I feel necessary to > actually use and recommend gnucap with gschem: > > 1) a way to define a permanent group of symbols that shall > participate in simulation. check. > > 2) predefined signal and probe symbols me too. > 3) a fairly complete set of models for basic analog > components yes yes > 4) a "simulate!" button to trigger the simulation and > yield output. and how about the ability to augment the schematic by showing the DC voltages at the nets? > The last two requirements are essential. Lack of immediately > available models is a show stopper for newbies. The models > don't have to be elaborated and can be idealized. But they > have to work with gnucap right away without manual tweaking. Before we can consider that, we need to have a flawless translation of the netlist. Those buttons are a waste if I need to manually edit the netlist. > The simulate-button requirement stands for a short round-trip > time. For me, simulation is all about tweaking the circuit > and watch out for the effect. It doesn't have to be an > actual button. Some kind of script or makefile run on the > *.sch file might do, too. It is for me too. I usually save the netlist, then run gnucap interactively, usually doing stuff that spice won't let me do. Then when the circuit is finally tweeked, how do I propagate the changes back to the schematic? (manually?) > > Most gnucap users are not geda users. The most active > > Gnucap users look at it as an alternative to high priced > > simulators like Spectre, Nanosim, BDA and Saber. Not > > (what they consider to be toys) like LTspice. > > Well, I am talking about usability not accuracy, speed, or > whatever the other simulators excel at. This might be a > different metric. I know. That is one of the reasons Qucs seems to be successful. The simulator engine is somewhat of a lightweight, and for big circuits it can be very slow, but people love it because it is easy for a beginner to use. What we should have here is an upgrade path, so when they outgrow Qucs, we provide what they need. > Do you you have some kind of vision on how gschem should > interact with gnucap? Take a look at Qucs. That's one way. The manual way of getting a netlist and running it manually must be available too. It seems you have a vision too. Let's make it happen. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Wednesday 18 August 2010, Oliver King-Smith wrote: > I am under the probably incorrect impression that LtSpice is > actually a better than ngspice and gnucap. What do you > think the benefits are gnucap vs Ltspice? Better for what? You got that impression because somebody is promoting it and you believe the ads. The biggest benefit of LTspice is that people like the user interface. Also, it comes with a library of stuff that some users like. The biggest drawback of the geda/gnucap combo is that the interface between gschem and gnucap works very badly, hence my request for help. Another issue with gnucap now is that there is a big difference between the stable branch and the development branch. Some of the most important features are only in the development branch, which is not the one you get with most Linux distros. For the benchmarks I have run, Gnucap outperforms LTspice and NGspice for medium to large circuits, sometimes by a huge amount. I recall one where Gnucap completed a transient analysis in a few minutes, NGspice took about 8 hours, and I gave up waiting for LTspice, which had produced no output after running it overnight. Also, Gnucap produces output along the way, so even with a slow run you get to see something soon, but either Spice doesn't show the user anything until it is all done. This is not a random difference. I fully understand the reasons for it. Another benchmark, run a long time ago, comparing a predecessor of Gnucap to an expensive commercial simulator that specializes in power grid analysis, the predecessor of gnucap outperformed the commercial package for power grid analysis. Gnucap is a lot more flexible that any spice. It has plugins for lots of stuff, including models, measurements, simulation languages. You can add new (lots of stuff) without recompiling or reinstalling. It takes several simulation languages, including spice, spectre and Verilog. Gnucap has more flexibility in how you run it, for example, you can do an AC analysis at an instant in time, such as a snapshot from a transient analysis. Spice only lets you do AC at quiescent. To see an example of where this matters, try doing an AC analysis of a class B amplifier. Gnucap's step control works better. One example of where this shows is in simulating oscillators. Gnucap is accurate enough to make distortion measurements on a sine wave oscillator. Spice isn't. Gnucap is accurate enough to properly simulate a negative resistance oscillator with a switch, and gives a correct waveform and correct oscillation frequency. Either spice gives nonsense on this circuit. Gnucap is not Spice. (in the same sense that Gnu's not Unix, or that C++ is not Fortran) Gnucap development is more focused on moving forward than bug-for-bug compatibility with legacy programs. That's just a little. But really, in free/open-source, or anywhere, you should expect tradeoffs. One will be better in some ways, another better in other ways. The question should not be which is better, but how do we make ours better. That's both better than it is, and better than others. And remember, things get better when you and we work to make them better, and worse when you see a perceived deficiency and run the other way, and worse when we deny the deficiencies and keep the status quo. The Gnucap development team is working on features for advanced users, with the intent of eventually fully supporting Verilog- AMS, through partnerships with some other GPL'd projects. What seems to be missing is the partnership with schematic and layout. It is in this area that help is most desperately needed. Gnucap/gEDA can be made to be better that LTspice (and others too) in every way, if we choose to do so. Let's do it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Multiple pages
On Tuesday 17 August 2010, kai-martin knaak wrote: > I tend to do simulation with ltspice. You have said many times how much you love LTspice, and how much you dislike the gEDA environment for simulation. How about stepping forward to do something about it? I have asked many times over many years for help with gnucap, especially with the gnucap/geda interface. Most gnucap users are not geda users. The most active Gnucap users look at it as an alternative to high priced simulators like Spectre, Nanosim, BDA and Saber. Not (what they consider to be toys) like LTspice. Therefore the development focus has been in areas that appeal to high end users, and not on the "low hanging fruit" that seems to be needed here. You can be a hero by applying your knowledge, bringing what you like about LTspice here, and helping to solve that problem you are well aware of. This is really an open invitation to anyone who wants to help, but Kai has been rather vocal about it, hence the personal invitation. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Commercial CAD, land pattern generators report
On Saturday 14 August 2010, Armin Faltl wrote: > I think I have the following options then: > > a) fix the bug myself and reinvent your convenience function > which is questionable > b) re-release my library under LGPL and ask you to resubmit > the patch with same license > c) open source or shred my application d) contact the author of the patch and ask if it is ok for you to use in your proprietary version. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Commercial CAD, land pattern generators report
On Friday 13 August 2010, Armin Faltl wrote: > I can't give an example on the intricacies of GPL v3 of the > top of my head, but wanted to write the following to RFS > regarding putting libraries under GPL instead of LGPL: > "I want to contribute or give away what I want to and keep > my own what I want to keep and if this is not possible with > a GPL-license on my own library liked to my own app, I just > won't use GPL!" I don't know who "RFS" is but any license you grant for your own code applies only to those to whom you grant the license. If you write some code, and it's yours, you can license it any way you want. If you make it available for download under GPL, this does not prevent you from granting any other license to anyone, as you choose. There is no requirement that you assign the copyright. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Commercial CAD, land pattern generators report
On Friday 13 August 2010, Kai-Martin Knaak wrote: > can you give an example, please? Under GPL-3 you can't make a contribution that applies one of your own patents, then sue the users of the package for patent infringement. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: New Poster - Trying to get ngspice up and running with gschem
On Tuesday 03 August 2010, Bill Gray wrote:
> To keep things as simple as possible, I am trying to simulate
> a voltage follower using an LM358 opamp. So far, I have
> been met only with abject failure, and my ability to
> continue investing time at this rate is waning... I have to
> get this project moving forward!!!
>
> I am running gschem, gnetlist, and ngspice on an ubuntu box.
>
> I have attached the relevant files to this email.
>
> As I said, I can get a simple voltage divider to work, but
> not the LM358 voltage follower circuit.
I see a few problems.
The first is "your circuit doesn't work", but I will get to that
later.
The next one is that this particular model is not compatible
with gnucap .. "POLY(5)".
For starters, I prefer to use a simple VCVS model for an opamp.
Then when that works, I switch to a more detailed model. Then
you could try the generic opamp model I posted a while back,
passing the appropriate parameters like slew rate and GBP.
Now back to "your circuit doesn't work" . If you want a
voltage follower, tie the output to the inverting input, and
drive the non-inverting input. You have the inputs swapped.
Here's an op-amp. To use this model, you need the development
version of gnucap.
* Generic op-amp behavioral model
.subckt opamp (out+ out- in+ in-)
.param gain=100k sr=1e99 clip=1e99 gbp=1e99
.param cc='1/(6.283185*gbp)'
.param ilim='cc*sr'
G1 (0 1 in+ in-) pwl ('-2*ilim','-ilim','-ilim',
+ '-ilim','ilim','ilim','2*ilim','ilim')
R1 (1 0) 'gain'
Cc (1 0) 'cc'
E1 (out+ out- 1 0) pwl ('-2*clip','-clip','-clip',
+ '-clip','clip','clip','2*clip','clip')
.ends
You can specify:
gain = open loop gain
clip = output clipping voltage
sr = slew rate (volts per second)
gbp = gain bandwidth product
There are default values, in case you don't want to specify.
To call:
X1 (out 0 in+ in-) opamp gain=10k gbp=1meg clip=13 sr='5/1e-6'
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gcshem to magic
On Sunday 01 August 2010, Oliver King-Smith wrote: > I have some analog circuits in gschem that I want to layout > in the magic vlsi tool. Is there a good way to go from > gschem to magic? Not that I know of. It is a rather difficult task to program. Magic is really a very simple chip layout tool, completely manual. It doesn't understand things like transistors. It's all polygons. You place regions of diffusion, poly, etc. Where poly overlaps diffusion a transistor is formed. > For example it would be nice to generate transistors > automatically (give w, l, and m) and then add port names > for S,D,G,B. Likewise it would be nice to produce a magic > compatible netlist, so the interactive router can then be > used once the cells are placed. > > Please let me know if there is a recommended way of doing > this? > > If you think there is a better way to tackle this problem > please let me know. Perhaps you should consider a higher level tool, such as electric, which does understand the concept of cells. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: anyone import into pcb a kicad netlist? I have kicad schematics and modules for all my parts but want to use the topo autorouter in pcb
On Friday 09 July 2010, al davis wrote: > > Can you provide links to the source of existing plugins? > > Gnucap source, the latest development snapshot. > http://www.gnucap.org/devel/gnucap-2009-12-07.tar.gz Forgot something ... The existing plugins are lang_*.cc . One file each. so .. lang_spice.cc lang_spectre.cc lang_verilog.cc ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: anyone import into pcb a kicad netlist? I have kicad schematics and modules for all my parts but want to use the topo autorouter in pcb
On Friday 09 July 2010, kai-martin knaak wrote: > > So ... any volunteers? > > What programming language? C++ > Can you provide links to the source of existing plugins? Gnucap source, the latest development snapshot. http://www.gnucap.org/devel/gnucap-2009-12-07.tar.gz There's also some documentation, although I know it is incomplete: http://gnucap.org/dokuwiki/doku.php?id=gnucap:netlist_import_and_export http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:tech:plugins The next release will be split, so there will be a gnucap_lib to link to, kind of like the geda_lib that gschem and gnetlist both link to. It may be appropriate that the gschem plugin links to geda_lib. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: anyone import into pcb a kicad netlist? I have kicad schematics and modules for all my parts but want to use the topo autorouter in pcb
On Thursday 08 July 2010, joshua wojnas wrote: > anyone import into pcb a kicad netlist? I have kicad > schematics and modules for all my parts but want to use the > topo autorouter in pcb Not that I know of, for now, but I want to take the opportunity to ask for help on a project that could provide this functionality. The project is language plugins for gnucap. A language plugin can read and write one format. I would like to recruit someone, maybe four people, to write four such plugins. They are: 1: gEDA/gschem 2: gEDA/PCB 3: Kicad schematic 4: Kicad layout There are existing plugins for Spice, Spectre, and Verilog, which gnucap uses. The Verilog format is sufficiently rich as to be able to convey all relevant information to and from any of the formats, so it could be used as a neutral interchange format. There's also a moth-balled, 95% complete, unreleased one for IBIS (version 3), which I will revive if someone else makes either #2 or #4 as listed above. These plugins interface to a library function that manages internal storage of the info. Gnucap is now using that library function. It is trivial to write a driver program that would use it to simply read one format and write another. This will be available in the next snapshot, and could be distributed separately to make a standalone translator. The basis of all of this is that it is translating circuit descriptions. Schematics and layouts are renderings of circuits, so the circuit description is augmented with rendering attributes. So, if we can get someone to write these four plugins, that will provide a migration path between Kicad and gEDA, both ways. It will also provide a path to simulation for both Kicad and gEDA, both from schematic and layout (enabling post-layout simulation). Providing any of the four is a valuable contribution in the sense that even one gives us functionality we don't already have that is known to be needed. gEDA currently provides a means of generating a Spice netlist, a fairly small subset of the spice language, but none of the other functionality mentioned here. So ... any volunteers? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RMS Waveform of a signal
On Wednesday 16 June 2010, Rubén Gómez Antolí wrote: > I have a signal with harmonics and distorsion and I want to > get the RMS waveform of it. > > I check some tools, including engines and post-proccesors, > with no success: Oscopy, Ngspice, Gnucap, Octave, KJWaves. > > Anyones knows or have some idea? The Gnucap measure command? http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:commands:measure http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual:measure:mean The rms value, for the entire run: measure sample = rms(probe="v(out)") The rms value, between two pre-specified time points: measure sample = rms(probe="v(out)" begin=4u end=6u) The rms value of a waveform, between the last two rising zero- crossings. measure t2 = cross(probe="v(out)" cross=0 rise last) measure t1 = cross(probe="v(out)" cross=0 rise last before=t2) measure rmsvalue = rms(probe="v(out)" begin=t1 end=t2) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Microwave simulation
On Thursday 29 April 2010, ignacio.dieg...@estumail.ucm.es wrote: > how can i perform scattering S-parameter analysis with gEDA? > Can i create a model from a s2p (touchstone) file model? Nothing with gEDA that does it directly and is ready to go. Your best bet is probably "Qucs". It's GUI driven, and focuses on RF. It also does a good job at the beginner level in general. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Sunday 25 April 2010, kai-martin knaak wrote:
> 6) Opamps:
> a) An ideal opamp with essentially infinite
> amplification, infinite slew rate, zero bias current, no
> input offset, etc.
Here's an op-amp:
* Generic op-amp behavioral model
.subckt opamp (out+ out- in+ in-)
.param gain=100k sr=1e99 clip=1e99 gbp=1e99
.param cc='1/(6.283185*gbp)'
.param ilim='cc*sr'
G1 (0 1 in+ in-) pwl
('-2*ilim','-ilim','-ilim','-ilim','ilim','ilim','2*ilim','ilim')
R1 (1 0) 'gain'
Cc (1 0) 'cc'
E1 (out+ out- 1 0) pwl
('-2*clip','-clip','-clip','-clip','clip','clip','2*clip','clip')
.ends
You can specify:
gain = open loop gain
clip = output clipping voltage
sr = slew rate (volts per second)
gbp = gain bandwidth product
There are default values, in case you don't want to specify.
To call:
X1 (out 0 in+ in-) opamp gain=10k gbp=1meg clip=13 sr='5/1e-6'
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Sunday 25 April 2010, kai-martin knaak wrote: > al davis wrote: > > Ah .. there's a good idea .. "don't have to be exact" .. > > they never are Not detailed, but just good enough > > for a beginner. .. Now we need a volunteer to do it. > > > > Have things like a generic parameterizable op-amp. .. with > > parameters like gain, gbp, and so on. > > Parameterized models are already for the user who got beyond > the first successful projects. For the first steps, there > should be as little room to screw up as possible. Not really .. remember there are default parameters .. x1 (1 2 3) opamp * all default parameter x2 (3 4 5) opamp gain=10k gbp=1meg slew=10e6 * some parameters specified > 2) diodes: Any generic diode would do. If in doubt, the > parameters of 1N4007 should do. already there, sort of .model d d D1 (1 2) d * all default parameters but I think what you are leading to is the need for something to "include" that has several of them with parameters defined. > 6) Opamps: > a) An ideal opamp with essentially infinite > amplification, infinite slew rate, zero bias current, no > input offset, etc. b) A more realistic model of a common > opamp, with bipolar input, e.g. OP07 > c) A more realistic model of a common opamp with FET > input, e.g. TL081 > d) A more realistic model of a common fast opamp, e.g. > LM833 > > 7) Comparators. Like with the opamps, an idealized model > should be complemented with a common real world component. > E.g. LM393 > > 8) Signal source with the capabilities of a simple frequency > generator (sine, square, triangle, pulses, sweep) has one -- spice doesn't Even with the spice-style "PULSE" and others ,, Gnucap lets you specify named values. I can not remember the order of the parameters needed for spice. > This set of components would already allow for lots of non > trivial simulation. Looks like it would be a nice package ,, Just "include" it in the netlist. > Other integrated components like analog > switches, voltage constants, transformers, or mixers would > be nice to have. But they are not essential to get started. > > > The vast majority of gnucap users are not geda users. > > This might change, if geda provides a way from schematic to > simulation that is as straight forward as the way from gschem > to pcb. I keep hoping. Another need is post-layout simulation. The dedicated SI simulators (Hyperlynx and others) have import filters for all of the commecial layout programs. We can have that too. I have IBIS stored away waiting for a reason to revive it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Saturday 24 April 2010, Armin Faltl wrote: > I can't "make" the list, but can tell you what I use: > > - resistor > - potentiometer > - capacitor > - inductor > - diode (including Zener, Schottky,... ) > - bipolar transistors > - MOSFETs > - op-amp > - Schmitt-trigger > - logic gates (NAND), sometimes abused as analog > - (crystal) oszillator > - differential/instrumentation/isolation amplifier > - switches > - timer (TLC555) Most of those are standard Spice elements, which are already there. Others .. can you be more specific on how you think they could be used? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Saturday 24 April 2010, kai-martin knaak wrote: > There should not be a need to search for specific models for > getting started with basic circuits in the first place. The > models don't have to be exact. But they need to be available > right away. > Ah .. there's a good idea .. "don't have to be exact" .. they never are Not detailed, but just good enough for a beginner. .. Now we need a volunteer to do it. Have things like a generic parameterizable op-amp. .. with parameters like gain, gbp, and so on. Can you make a list of the ones that should be included? On Saturday 24 April 2010, kai-martin knaak wrote: > As for the site: IMHO, the gedasymbols concept is a success > -- It is a central site. Yet, every contributor is > exclusively responsible for his or her own slice. I see no > compelling reason to not use gedasymbols.org for simulation > models, too. If you are annoyed by the name, an alias > "gedafiles.org" may be a solution. No .. the name is not a problem. The vast majority of gnucap users are not geda users. I think that is true of ngspice too. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: A little puzzled about the purpose of gschem
On Saturday 24 April 2010, Link wrote: > I hadn't intended for anyone to interpret it that way, and > I'm sorry if you interpreted that as bashing gEDA. Perhaps > my choice of words was rather unfortunate. Apology accepted. > What I intended to is that one component (the simulator) of > LTSpice tends to perform better _for me_ than gEDA's > equivalents, in sheer terms of the simulation results being > what I expect. I'm not sure if that is even a problem with > gnucap/ngspice or if I'm simply doing something wrong > myself, but I do know that I find LTSpice easier to use for > simulation. That does not mean I dislike gEDA, or think it's > bad, or anything of the sort - in fact, I find it to be > absolutely brilliant for schematic capture and PCB design. There is a real problem with the way "gnetlist" works. (contrary to what some others here say). I have known this for years. Often people have trouble with it. I don't know what to say. It seems I always need to hack the netlist. I have tried to recruit help on this, specifically making gschem and pcb plugins for the gnucap translator system. No takers. Maybe when I get my other pile of work out of the way I will do it myself, for both geda and kicad. Then "gspiceui" doesn't help. I don't like that style anyway. For a beginner, combined with how gnetlist works, I don't know what to do. In this environment, it's not gnucap or ngspice that is the trouble spot. It's gnetlist, documentation, and communication between tools. So the situation here is that people don't see the capability that ngspice and gnucap have because of problems elsewhere. The other problem people run into is that nobody here has collected the hundreds (thousands?) of models (of all kinds) that come from all over. A commercial organization can pay a junior person full time to maintain the collection. That's what it takes. Not in a commercial environment, this kind of thing has to be done by the community, a shared effort. But really "google for it", and "check to see if it makes sense" is the correct answer. A lot of those models don't make sense for the particular application people are asking about. The big collection that LT and P spice have, that is still incomplete because it is impossible to be truly complete, lulls users into a false confidence. As far as simulation results go .. If it gives you trouble, please report it. I'm well aware of the Spice3f5 false convergence issue, and that it still exists in NGspice. I'm well aware of the NGspice step control bugs, where an attempt to fix 3f5 problems really made it worse. I am not convinced that LTspice is any better in these issues than NGspice. As far as I know, Gnucap doesn't have these problems. Convergence and step control are never perfect. It seems to work for me, but if it doesn't for you, the only way it can get better is if you let me know about the problem, and send a test case that demonstrates it. The benchmarks I have tend to show that Gnucap usually outperforms NGspice on difficult circuits, and that LTspice usually performed about the same as NGspice. NGspice is often faster than Gnucap on small circuits, where both are fast enough that it doesn't really matter. The last time I made any of these comparisons was a few years ago, so some things might have changed. Gnucap has improved, perhaps LTspice has improved too. NGspice hasn't really changed in this regard. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Saturday 24 April 2010, Kai-Martin Knaak wrote: > Please do so. > Lack of models is a major road block to get started with > simulation. Once over the new users stage, more models will > help to make even more. > > The more models in the quiver, the more gnucap users, the > more new models. Let's get this felicitous circle rolling! > A model site should be "models" not just "spice models" to leave it open for all kinds of models. There's also Verilog models, IBIS models, and many others. From what I see, the preferred language of most modeling work being done now is Verilog-AMS. The problem is not a lack of models, but rather a lack of a beginner-friendly way to find them, and the lack of a beginner- friendly way to determine which if any of those you find are suitable for your application. This is the idea of Werner's model site. Unfortunately, it is not organized in a beginner friendly way. It's a start and needs to be developed. gnucap.org is a wiki. If someone wants to take on the task of making the model finding process easier, that would be most welcome. There is space available. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Saturday 24 April 2010, Andrzej wrote: > Do you have any plans for releasing the new version? If so, > what would be its scope. I'm afraid that if it is going to > include all the planned features (which are pretty > ambitious, I must admit), it will remain a development > version forever. Some programs do remain as development versions forever. Snapshots are closer to release than CVS. Sometimes the difference is just what you call it. You can download the development version: http://www.gnucap.org/devel/gnucap-2009-12-07.tar.gz There are other tarballs with plugins there, which you might want, including all of the BSIM models including the latest BSIM4 and SOI. I guess you could think of it like the stable and unstable versions of Debian. What is holding up a stable release now is primarily build and install issues. Actually, that has been the holdup for a long time, but kept getting preempted by new features that active users asked for. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: A little puzzled about the purpose of gschem
On Friday 23 April 2010, Link wrote: > Eh? > Suppose you had instead said: === > .. I suggest > using Eagle through Darwine. In my personal experience, > Eagle is a lot better than geda, and > it is definitely an easier workflow. === Is this any different? No. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Friday 23 April 2010, D T wrote: > Thank you Al. Just for the record: ngspice worked; gnucap > didn't. Details follow. > > The directions from the subckt section of the NGSPICE User > Manual > (http://ngspice.cvs.sourceforge.net/viewvc/*checkout*/ngspic > e/ngspice/ng-spice-manuals/manual.pdf?) did their job exactly > as described. > > The directions from the GNUCAP's page: > http://www.gnucap.org/dokuwiki/doku.php?id=gnucap:manual:com > patibility:subcircuit_with_parameters > > didn't work for me. Here's the error message followed by the > test code ran on gnucap-0.35 > > ---gnucap> get > X2Y_test.cir > > * X2Y capacitor the GNUCAP way > .subckt CX2Y 11 12 13 14 (CAP=22nF ESR=0.052 ESL=0.75nH) > ^ ? subckt default parameters not > supported yet > Get a newer version of gnucap. What doesn't work in 0.35 is that syntax for specifying default values. Passing parameters works. Get the latest snapshot, where it all works. The wiki is for the snapshot. Based on the date, 2009/10/04, still not the latest. In the latest version, the LTspice syntax works. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: passing parameters to a subckt
On Friday 23 April 2010, D T wrote: > Hi,I have the feeling this has been a topic here already. > Nevertheless, is there a way to pass parameters to а subckt > for spice3f5/ngspice/gnucap in linux similar to what PSpice > and LTSpice have? > Of course there is. Well .. not spice 3f5 but gnucap does, and I believe ngspice does, in the latest version. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: A little puzzled about the purpose of gschem
On Thursday 22 April 2010, Link wrote: > However, if you want a quick, graphical SPICE, I suggest > using LTSpice through Darwine. In my personal experience, > LTSpice's simulator is a lot better than ngspice/gnucap, and > it is definitely an easier workflow than > gschem->gattrib->gnetlist->ngspice if you're only interested > in simulation. One reason commercial software (including zero-dollar commercial software like LTspice and the light version of Eagle) may be better in some ways is that some people choose to bash rather than to enter a dialog that could be helpful. If you look at free/open-source software as a product to be consumed, like you consume commercial products, you will probably be disappointed. If you are looking for a handout, sorry, it doesn't work that way. On the other hand, if you appreciate the openness, and want something more organic, free/open-source software opens up possibilities that commercial software doesn't come near. If you want to learn by getting involved with a project, free/open-source software offers big opportunities to learn and connect that you can't get anywhere else. These opportunities are offered to EVERYONE, not just "A students". I find it somewhat ironic that "penguindevelopment.org" doesn't seem to understand the concept. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: hydraulic symbols and schematics
On Thursday 08 April 2010, Kai-Martin Knaak wrote: > This is one of the strange consequences of the common law > system. In the rest of the world, where civil law is > applied, ignorance of the delinquent does not diminish the > forfeit. > It isn't law that you could be ignorant of. It's a "work". If you know about the "work" and do something like it, they have a strong case that yours is influenced by theirs. If you don't know about something, you can't copy it, and you are in a stronger position to defend that you did it independently. It's not just patents .. It applies wherever there is "intelectual property", such as trade secrets. Signing a non-disclosure agreement is dangerous in a similar way. The EDA business is small and tight. If any EDA company were to attack gEDA, the biggest impact would be in publicity (negative for them, positive for us). I don't feel threatened. Hey, Synopsys, come and get me. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: hydraulic symbols and schematics
On Wednesday 07 April 2010, Dave McGuire wrote: >Ok, that's fine by me, as it's your list. But could you > explain how it could be dangerous? That suggestion sounds > quite ludicrous to me. In general, it really does present a huge legal risk, so I agree with the policy. In this case, the patent is so old that it has gone into the public domain long ago. A long time ago, all this stuff we consider to be so basic was new. The concept of duality between different types of "circuits" is well known, and taught in undergraduate engineering courses. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: hydraulic symbols and schematics
On Wednesday 07 April 2010, Bert Timmerman wrote: > Do not discuss patents here please ! Did you notice the date? (1934) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: hydraulic symbols and schematics
On Wednesday 07 April 2010, Stuart Brorson wrote: > > Do you foresee any other difficulties? ... aside from > > simulating a hydraulic circuit with spice or generating a > > layout. > > Actually, my first thought was: What kinds of simulations > (if any) does one do in hydraulics? Are there any standard > simulators? If so, generating a netlist to feed to such a > simulator might be an interesting hobby project. If simulation means Spice to you, you are 20 years behind. Looking to the past ... Simulations of things like this were (and are) often done on a proprietary commercial simulator "Saber", using a proprietary modeling language "Mast". Matlab/Simulink is also popular (and proprietary). Looking forward ... Things like this can be done very well in Verilog-AMS, which has a published standard, cleaner syntax, and several commercial implementations. Many users of Saber and Mast are switching over. Gnucap provides partial support for Verilog-AMS, and is working on more complete support. ___ 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 Monday 15 March 2010, Dave McGuire wrote: > On Mar 15, 2010, at 12:32 AM, Dan McMahill wrote: > >>> With the help of Ivan I'm writing a viewer, oscopy > >>> (http://repo.or.cz/w/oscopy.git) based draft #4 of this > >>> page: > >>> http://geda.seul.org/wiki/geda:data_plotting_improvements > >> > >> IMHO, there are already very mature open source data > >> plotters out there. Think gnuplot, or grace. What is the > >> rationale in rolling your own? > > > > unless I'm missing some key feature of gnuplot and grace, > > they stink for plotting simulator output. > > > > I spend a *lot* of time looking at simulator output and > > some of the things which are used over and over again are > > easy interactive zoom in/out, panning at a fixed zoom, > > putting cursors on waveforms that will lock onto the actual > > datapoints, having delta cursors, and having a flexible and > > *extensible* waveform calculator. The types of > > postprocessing range from the very simple (out_plus - > > out-minus) to more complex but standard like an fft to > > fairly complex custom functions. > > Good heavens. That's the sort of stuff I do with a > digitizing oscilloscope. I could never imagine doing that > with simulator output. Because you have never used a good simulator/schematic combination. What Dan describes is not only doable, it is what is needed to be taken seriously. Nothing less will do. The functionality of a digital oscilloscope is the minimum. Build that as a base, then you can start to think of what is really needed. I use gwave. It is the best so far, but there is a lot of room for improvement. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: NE 555 and simulation issue
On Tuesday 02 March 2010, Peter Clifton wrote: > Gnucap is another advanced simulation environment which might > be interesting. It is different to spice, but can accept > spice syntax and models etc.. Again, milage will vary as to > how well it works with a given model - and it is by no means > a drop in replacement for spice, some things are just done > differently. > > Al might chime in and give more info if I've got anything > wrong here, as I'm certainly not an expert - and Al ought to > know, since he writes Gnucap. Gnucap is not designed as a drop-in replacement of Spice. That would be a waste of time. Rather, it is designed as a followup to Spice, bringing free simulation up to date, and hopefully taking the lead. In commercial simulators, there are lots of them that are just Spice. In that regard, NGspice is our spice. Then there are those that move beyond, in many ways. They sell for a much higher price than any Spice. This is the "mixed signal", "fast spice" and lots of others. The only reason they haven't completely replaced Spice is MARKETING. They can sell a Spice cheap, and make big bucks on the new one. Gnucap is designed with full knowledge of Spice and others, to address the big shortcomings of Spice, and move on. I am referring to the real issues here, not the ones that can be easily fixed. Unfortunately, progress has been hampered by a development team that is far too small, and not much open community involvement. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: TO-92 Best Practices
On Wednesday 03 March 2010, Dave McGuire wrote: > > Maybe they are like me and don't have the eyesight, > > equipment or dexterity to solder anything smaller than > > TO92 parts? > >We've had these neat things called "magnifying glasses" on > the market for at least a few months now. And when the > proper equipment can be had for less than $100.. Along that line ... You could get what they call "reading glasses" from a supermarket. Get the strongest ones they have. They make great magnifying glasses. You really should wear eye protection while soldering anyway. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: NE 555 and simulation issue
On Tuesday 02 March 2010, Geoff Swan wrote: > It has been my experience that circuit modeling tools > although useful are not able to negate the need to > understand the low level principles of the underlying > circuit. The better you understand the physics of what is > going on the more value you will get from your circuit > modelling. > That is one of the reasons I often recommend using simple models of things instead of the ones you can download. It seems this is not taught in schools like it should be. Instead, they teach "professional" (ha) tools, often without knowing what professionals use or how they use them. Simulation is very useful as a study aid to help understand the low level principles. Unfortunately, very few texts and very few professors use it this way. They teach simulation strictly for validation, not for exploration, and don't even do a good job at that. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: I am such a troll for posting to slashdot
On Saturday 27 February 2010, Bob Paddock wrote: > The other thing that is holding back gEDA Schematics is the > lack of available publication quality symbols. If I'm doing > a PCB I use gEDA. If I'm after a nice looking schematic I > use XCircuit. I'd like to be able to have it both ways, a > nice looking schematic that I can make a PCB from. For hobby use, I doubt if they notice. Even for pro use. Have you see the symbols you get with some of the high priced packages? The gEDA symbols really look good by comparison. The gEDA symbols are better looking than the Kicad symbols. Of course I won't complain if they get better. There is a need for a migration path, for migrating both schematics and symbols. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Sunday 28 February 2010, John Doty wrote: > Ah, but it has an open interface we can use. A great strength > of gEDA is that the tools play well with other tools, > whether they are part of gEDA or not. I don't care how many proprietary tools you can leverage by starting the schematic on gschem. I do care how much of a design you can do with a 100% free/open- source flow, and how well that kind of flow works. I do care about a migration path to encourage people to move from proprietary flows to free/open-source flows. I do care about cooperation between free/open-source tools, whether they are part of gEDA or not. I do care about welcoming those who are making free/open-source tools, adding to how much of a design you can do with a 100% free/open-source flow, whether they are part of gEDA or not. I do care about welcoming researchers, who are creating the new state of the art, the tools of the future. I do care about welcoming hobbyists, who are creating our culture and future. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA user: gnetlist -gdrc buffer overflow and gnetlist -gspice-sdb killed
On Saturday 27 February 2010, John Doty wrote: > It looks like you're using the kind of hierarchy suitable for > a printed circuit flow, not a SPICE/ASIC flow. I suggest > first reading the excellent tutorial at > http://www.brorson.com/gEDA/SPICE/intro.html. > Ouch .. That was written 6 years ago when things were very different than they are now. LTspice is as much not a part of gEDA as Eagle is. Promoting it here is the same as promoting Eagle. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Eagle to gEDA conversion path??
On Tuesday 23 February 2010, Dave N6NZ wrote: > Really? Is there a use for gEDA->Eagle? Lots of reasons. Whether you like it or not, it is popular. Some people will insist on it. If gEDA is ever to replace Eagle, there needs to be a migration path both ways. If Free/open-source is ever to make it to the mainstream, the various free packages need to share. That includes Kicad. Regarding Kicad and gEDA, think of it like vi and emacs. It must be possible to use them interchangeably, but you will never convince a fan of one to use the other, and it will harm both if you try. > > I never would have cared about Eagle, except that the RepRap > PCB's are done with Eagle. Now, why someone would do open > source hardware with closed source tools is a mystery to > me... but anyway so far in a total of 30 minutes of > Eagle usage I've discovered: 1) the crippleware version only > allows a single schematic sheet, leading people to create > unreadable glop, and 2) printing is truly bizarre. I can't > imagine someone going from gEDA to the free/crippled version > of Eagle. > And as to going to the commercial version, OK I > can see some customer requiring that, but isn't that Eagle's > problem? No. They are on top. Remember the golden rule: He who has the gold makes the rules. They have no business reason to cooperate. > After all, nobody is hiding gEDA's file formats. True, but they are not really designed for general exchange. Rather, they are more like a dump of the internal representation. There is no possibility that anyone outside would adopt such a tool-specific format. For interchange, it is necessary to abstract the content to something that is equally meaningful in all contexts. Don't forget .. there is layout too, and lots of other tools and ways to use it. The only representation that is equally meaningful in all contexts is a circuit, a netlist. Then augment it with the extra information needed to render it as a schematic, and as a layout. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: analog/code co-simulation and schematics and netlists for silicon
On Tuesday 23 February 2010, John Griessen wrote: > Al, are you saying that Icarus verilog would run along side > of gnucap once that interface is ready? Icarus has two key parts .. A compiler, and a virtual machine. In its normal use, the compiler generates code for the virtual machine, then you run the virtual machine on that code. The icarus compiler has a provision for alternate "target" back ends. There are several available. -- fpga, pal, vvp, . The plan is to make a new target back end that will generate a gnucap model plugin. For gnucap, the Icarus virtual machine will not be used. In gnucap (development version, not 0.35) .. device models are not built-in, but can be loaded and unloaded at run time. This makes it possible to have a lot more models without the bloat of all of the models you are not using. (I'm not talking about the spice ".model" statement here .. This is the real code that implements the model.) These model plugins are standard shared-object files native to whatever system you are running on. As it stands now, some are hand coded in C++, some use the old "gnucap-modelgen", and some are spice models. Gnucap can use unmodified Spice C model code as plugins, with a simple interface wrapper. The work in progress is along two lines .. One is an Icarus backend to generate a plugin. The other is to use another model compiler "ADMS" to generate gnucap code. You can use ADMS now to generate NGspice code, which gnucap can use as a plugin, but this is not as efficient as it should be, because of the ancient Spice interface overhead and mapping overhead. As another approach, it is possible to run the Icarus virtual machine "along side of gnucap", but efficiency is not good, and you need to hack some code. It has been done. > Would you still use gschem/gnetlist to schematically connect > verilog modules? That depends on having a good translator > first, right? Anything that generates a netlist. Gnucap uses "language plugins" to read whatever input format. Maybe someone could make a language plugin to read and write the gschem format directly. Once this is done, it will also give us a stand-alone translator, both ways, between any of the supported formats. > Could you just use a top level schematic as a guide for > connecting code modules to simulate with no netlist > generated from gschem? Sure, but do you want to? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: analog/code co-simulation and schematics and netlists for silicon
On Tuesday 23 February 2010, John Griessen wrote: > Anyone have any ideas you'd like mentioned to him? Questions > I should ask? I'm just planning on telling him the status of > verilog-ams backend of gnetlist and that it can run some > simulations from a netlist -- the way it needs to be for > many chip design/verification work flows. Just in case > there's any development money or new developers available. It really doesn't work .. sorry. Gnucap (the development version) will take netlists in Spice, Spectre, or Verilog formats. The gnetlist backend only supports a small subset of what could be done. For years, I have accepted the fact that the generated netlist has some flaws and requires manual editing. I can deal with it, unhappily, but most beginners can't, and most people who might think of migrating won't even if they could. We really need a more general translator, that isn't based on the gschem format or any other tool specific format. I have a start, but need help. > Reference: http://www.edn.com/article/CA6670945.html > > “We have been working with Keil to simulate mixed-signal > peripherals. But, eventually, we are going to need a full > analog/mixed-signal simulator on the desktop—something that > can pull together Verilog, Spice, and software simulations > on the desktop for a low price,” he says. “We are still > searching.” Reid Wenders EDN, 7/23/2009 If I can get some help with Gnucap, this will happen. Actually, I do have some help now, but need more, especially people to work on user oriented issues, what most people think of as the easy part. Gnucap was designed for mixed signal from the beginning, long before there was such a thing as Verilog-AMS. What is lacking is a fully working model compiler. There is work in progress with Icarus to make this happen. The main missing piece now is a back-end for Icarus that matches the gnucap interface. That is really the only critical missing piece. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Eagle to gEDA conversion path??
On Monday 22 February 2010, Dave N6NZ wrote: > Is there any automated Eagle to gEDA conversion path? > > (He says hopefully, but knowing it's highly unlikely.) No .. but since you mention it, it is time to ask again for help in making something that will do this. I proposed a translator system, using an intermediate language, to translate both ways between schematic, layout, and simulation. It needs to happen. I don't have time to do it completely, but will guide if someone steps up to do some coding. Kicad needs it too. It can be a joint effort, which will strengthen both geda and kicad. There is a long list of translations that are needed. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: why separate xgsch2pcb?
On Tuesday 09 February 2010, Peter Clifton wrote: > Not for a GUI, it isn't. Seriously. Right concept, bad > integration. > A GUI is just a visual aid. If you have junk under the hood, and hide it with a GUI, you just have more junk. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: OT: Latex
On Sunday 07 February 2010, Kai-Martin Knaak wrote: > Is this intentional, > or just due to a lack of developer cycles? We are waiting for you to do it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very simple gnucap simulation
On Thursday 04 February 2010, Chris Cole wrote: > and gwave shows up with correct Vin and Vout parameters, but > no data is graphed? > The plot would be too cluttered if it showed everything. You need to drag the signal you want to see over to where you want to see it. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: very simple gnucap simulation
On Wednesday 03 February 2010, Chris Cole wrote: > gnucap> tran 1s 10s > > #Time > 0. > 1. > 2. > 3. > 4. > 5. > 6. > 7. > 8. > 9. > 10. > > Any suggestions? > You need to specify what to print first. Before the tran command do something like: gnucap> print tran v(nodes) i(D*) depending on what you want to see. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Parts Manager Working Document
On Friday 08 January 2010, Edward Hennessy wrote: > I created a working document for a gEDA parts manager on the > gEDA wiki. > > http://geda.seul.org/wiki/geda:gparts_dd > > If anyone has feedback or specific requirements, please > provide feedback to geda-dev or geda-user mailing > lists. I'll continue to update the document as the project > progresses. It should have "simulation models" not "spice models". Spice models are one kind of simulation model. We should not restrict it to only one, especially when other kinds are already supported by geda-related tools. For example, there are Verilog models, VHDL models, IBIS models, Spectre models, and many others. They need to be all handled on an equal basis. Also, there aren't really "spice models". There are Hspice models, Pspice models, LTspice models, ... and for spice- derivative simulators under different names, .. Eldo, multi-sim. There are often several different models available for a device. The database needs to accomodate multiple models that a user can choose from. You don't need to explicitly support anything in particular, just general models, and more than one choice. Also .. Do not make the types of electronic components (diodes, resistors) inherent in the data base. They are just parts, and all parts have schematic symbols, layout footprints, and simulation models. Don't even try to make any specific device types inherent to the database. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Parts Manager Working Document
> On Jan 19, 2010, at 3:41 AM, Florian Teply wrote: > > Anything else to add?? > I guarantee you will leave something out, and that you will include some useless stuff. Just make sure the design is such that fields can be added and removed in the future without breaking anything. Same goes for device types, and lots of other stuff. v ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: teardrop compiling installation,
On Sunday 03 January 2010, DJ Delorie wrote: > You need to get the sources for PCB - installing a > binary-only package is not enough to let you build plugins. In the next official release of gnucap, installing a binary-only package IS enough to build plugins. That's true of the development snapshot now, but I am not aware of any binary packages. That is one of the major goals of this release. I expect plugins to be updated much more often than the core. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-12-07
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-12-07.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-12-07-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-12-07-models-jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-12-07-models-ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-12-07-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-12-07-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-12-07.md5sum Most users probably don't need to upgrade. If you are having trouble with an assert failure when using Spice model plugins, or if you are developing plugins, you should upgrade. This release has one minor bug fix in spice-wrapper.cc, and some changes to the interface to simulation data. The bug would cause an assertion failure, with some circuits. It is minor in the sense that the real code was correct. It was the check that was wrong. You could just remove the line with the failure. There is a proper fix in this release. There are changes in organization regarding the "language" plugins, changing them to single files which will make them easier to manage as plugins. This change is not significant to most users. There are changes to the access to simulation data. In particular, there are new files "sim_data.h" and "sim_data.cc", and static pointer "_sim" in CKT_BASE. This is probably not significant to most users, but if you have any custom plugins, they will need to be changed. There are two reasons for the change. The first is to improve incapsulation, making a cleaner boundary between core and what could be a plugin. The second is as a step toward being able to store multiple simulation runs for postprocessing. As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . You need to recompile all of the plugins with the new headers and wrappers. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: trying to compile gwave 20090213
On Monday 16 November 2009, KURT PETERS wrote: > What do you intend to use gwave for? Is it for viewing SPICE > output? Some people use it for Spice output. Some people use it for Gnucap output. It fits very well with running Gnucap interactively. I think most gnucap/gwave users are not using gspiceui. Personally, I use gwave with gnucap as my primary viewer for gnucap, but gspiceui (and anything like it) just gets in the way so I don't use it. Getting back to the original question >From what I have seen, gwave compile problems are usually (perhaps always) due to a missing library. For some reason I can't figure out, the guile libraries have different names on different systems, so it is hard to figure out which one is missing. It's too bad autoconf isn't more helpful at identifying what is missing. Without autoconf, what files are missing is obvious when it fails to compile, so I would ask the package manager what package provides that file, and install that package. With autoconf, you can look at the log, and see what test failed and how it failed. With patience, eventually you will find it. For another clue, look at other distributions that have gwave packages and see what the dependencies are. I believe Fedora and Debian (and their derivatives) have working gwave packages you can look at. Unfortunately, I don't remember what the name of the missing package was, other than that it was different from what autoconf said it was. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-11-10
There is a new development snapshot available ...
http://gnucap.org/devel/gnucap-2009-11-10.tar.gz
Optional plugin files:
http://gnucap.org/devel/gnucap-2009-11-10-models-bsim.tar.gz
http://gnucap.org/devel/gnucap-2009-11-10-models-jspice3-2.5.tar.gz
http://gnucap.org/devel/gnucap-2009-11-10-models-ngspice17.tar.gz
http://gnucap.org/devel/gnucap-2009-11-10-models-spice3f5.tar.gz
http://gnucap.org/devel/gnucap-2009-11-10-tools.tar.gz
This file contains the md5sum of the other files, so you can
check for a proper download:
http://gnucap.org/devel/gnucap-2009-11-10.md5sum
This release has changes to the "elaboration" phase of simulation.
There are three differences you will see ..
1. (Important!)
It fixes a bug that sometimes caused incorrect parameter values
in some cases. The bug would manifest with a certain combination
of subcircuits, models, and parameters.
In particular, something like this would give bad results:
.subckt foo (a k)
.model dio d (is={isat})
dfoo (a k) dio
.ends
...
x1 (1 2) foo isat=x
x2 (2 3) foo isat=y
...
.param x=1e-12
.param y=1e-11
.op
.param x=1e-13
.param y=1e-14
.op
.. would have the wrong value of isat,
probably keeping the original value.
Circuits that did not have this combination of models, subckt, and params
did not have this problem.
It's fixed now.
2.
Expressions with "E" notation (1.3E-6) would sometimes not be
evaluated properly. This is fixed.
3.
Expressions with function calls would sometimes not be
parsed correctly. Usually, you could work around this
by careful use of parentheses and quotes. It should
work now without the tricks.
As usual, to get started you need only the main package
gnucap-2009-xx-xx.tar.gz .
You need to recompile all of the plugins with the new headers
and wrappers.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gnucap development snapshot 2009-09-28
On Monday 28 September 2009, A.Burinskiy wrote: > I have difficulty getting raw file as an output of simulation > using version that is shipped with Fedora 11. Does > something changed since that time? Or how I could get raw > file out of simulation? (I'm going to try big simulation > that produces a lot of data) Gnucap doesn't produce a Spice-style "raw" file. Instead, the output is in text files that are readable by almost everything else. At some time in the future, probably near future, the output will be pluggable too, and maybe somebody will make a plugin for a new efficient format like HDF5. The spice raw file is kind of a pain because there are several different incompatible versions of it. The version supplied with most distros is the "stable" version from about 2 years ago. There is a lot of new stuff in the development version. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-09-28
There is a new development snapshot available ...
http://gnucap.org/devel/gnucap-2009-09-28.tar.gz
Optional plugin files:
http://gnucap.org/devel/gnucap-2009-09-28-models-bsim.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-jspice3-2.5.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-ngspice17.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-models-spice3f5.tar.gz
http://gnucap.org/devel/gnucap-2009-09-28-tools.tar.gz
This file contains the md5sum of the other files, so you can
check for a proper download:
http://gnucap.org/devel/gnucap-2009-09-28.md5sum
This release has changes to the "elaboration" phase of simulation.
There are three differences you will see ..
1. (Important!)
It fixes a bug that sometimes caused incorrect parameter values
in some cases. The bug would manifest with a certain combination
of subcircuits, models, and parameters.
In particular, something like this would give bad results:
.subckt foo (a k)
.model dio d (is={isat})
dfoo (a k) dio
.ends
...
x1 (1 2) foo isat=1u
x2 (2 3) foo isat=2u
...
.. would have the wrong value of isat.
Circuits that did not have this combination of models, subckt, and params
did not have this problem.
2. (cosmetic)
Taming of redundant warnings that would be printed in the
elaboration phase. Also, bad parameter warnings from
spice models using plugins are now printed, only once,
on readin, instead of multiple times on elaboration.
3. (new models)
The tarball "models-bsim" includes new models, including
the new BSIM4SOI, released Sep 22 and the new BSIM465,
release Sep 9.
===
As usual, to get started you need only the main package
gnucap-2009-xx-xx.tar.gz .
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-09-22
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-09-22.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-09-22-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-09-22-models- jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-09-22-models- ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-09-22-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-09-22-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-09-22.md5sum New features: "gmin stepping" homotopy for convergence improvement. === As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Library of gnucap and ngspice compatible models?
On Tuesday 15 September 2009, asom...@gmail.com wrote: > I, and judging from the mailing lists and forums many others, > are frustrated by the difficulty of finding spice models that > are compatible with open-source circuit simulators. Yes. It's a problem. It's the kind of problem that will require constant attention to keep it up. > Common > replies are "you don't need that level of detail" or "find a > model library buried in the vendor's website, pick a model > for a part similar to yours, then alter any lines containing > X and replace .subckt Y with a reference to your Z". But > that's annoying, especially for users who are new to these > simulators. I confess "Find a model ... alter any "I admit telling people that. I don't like it, but that's all we have. "you don't need that level of detail" ... When I said that, I can see that the asker is buried in complexity and needs to simplify. It's a different problem. There is a problem with teachers that show simulation as draw the picture, push a button, and scope-like picture magically comes out. When I was teaching, I tried to do better, but it's a real battle. > So my question is, should I make a new project which is a > library of models to use with open source simulators? I > think that there is a need for such a thing, but would it be > a good idea? I think the best approach is a wiki, a way to get tarballs from the wiki, a way to search, and simple way to access it inspired by the way Linux distros install from their repository. The more I think about it, the more it looks like what Linux and BSD distros are doing with applications. Make a plan for how it is organized, begin to populate it, and invite others to help. There is lots of space on the Gnucap wiki. It's not just Spice models. There will never be a significant number of "Gnucap models". Rather, Gnucap needs to read standard models, and models designed for other simulators and other uses. Looking forward, Verilog-AMS, VHDL-AMS, and System-C are becoming more popular. Looking back, there are lots of IBIS models. There is also different meanings of "model". To some, it is a spice ".model" statement or subcircuit. To others, it is the C code with the actual model equations. It's really models that depend on other models, which may or may not already be there. > Licensing should not be a problem; most vendors > license their models to permit redistribution. Licensing really is a problem. It goes the whole range from freely redistributable to available only after signing a nondisclosure agreement. If you look at any of the Linux distros, you will see ways of dealing with it. > Would it be > better to incorporate these into some existing project than > to start a new one? I think you need to start a new one. I have space for you at gnucap.org. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-09-09
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-09-09.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-09-09-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-09-09-models-jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-09-09-models-ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-09-09-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-09-09-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-09-09.md5sum New features: "Binning" (automatic model selection) now works for some spice models. The BSIM3 and BSIM4 models now support binning. Others can be made to support binning in the future, by a change in each wrapper.h. For now, just the BSIM models support binning. I believe this is consistent with commercial simulators. Bug fixes: Certain user errors could cause a crash when using spice model plugins. This is fixed. Existing binning, with the embedded (modelgen based) BSIM models could fail when the binned parameters use expressions. This is fixed. === As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-08-22
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-08-22.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-08-22-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-08-22-models-jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-08-22-models-ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-08-22-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-08-22-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-08-22.md5sum This is a bug fix release. There was a problem that would lead to an assert fail with some spice model plugins using spice-wrapper.cc. The bug is a consequence of incomplete initialization of internal nodes of spice devices. The problem was expressed when continuing an analysis after a structure change. Certain non-analysis commands such as the ones that set up probes set up to analyze, so they too could trigger the bug. A sequence like: probe or analyze a topology change probe or analyze .. would trigger the bug. The only file that must change is spice-wrapper.cc. This file is not used by the core, but is used by all spice model plugins. The web site http://gnucap.org now links to the wiki, which is now the official web site. The manual: http://gnucap.org/dokuwiki/doku.php?id=gnucap:manual === As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-08-19
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-08-19.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-08-19-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-08-19-models- jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-08-19-models- ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-08-19-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-08-19-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-08-19.md5sum Changes--- 1. fix const portability bug, in response to several bug reports. 2. Parameter expression evaluation improvements. Scoping of variables should be correct now. 3. Verilog and Spectre mode improvements. There was a bug introduced 06-11 which often caused it to not work with files, but it did work interactively. The bug was in code to skip the spice title line, but it had other consequences in some cases. The web site http://gnucap.org now links to the wiki, which is now the official web site. The wiki: http://wiki.gnucap.org The manual: http://wiki.gnucap.org/dokuwiki/doku.php?id=gnucap:manual === As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . ___ 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 Saturday 15 August 2009, r wrote: > On Sat, Aug 15, 2009 at 5:12 AM, al davis 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)? You cannot possibly know about all possible symbols that may be created in the future. So, the netlister cannot have explicit knowledge of them. It must work in general. > > 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. You cannot possibly know about all possible netlist formats a symbol might be used for. A netlister for an irregular output format might need to key on some attribute to decide what to do, but this is not the symbol itself. You could define an attribute that identifies special properties, and the netlister could key off of that. How about a "special_target" attribute, where you could specify special treatment. ___ 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 Saturday 01 August 2009, A.Burinskiy wrote: > And, finally, me, as a user, will not be happy to change the > script each time I add new symbol! Good thing you mentioned it. Unfortunately, the Spice format is very irregular, so dealing with it is pure hell. That is one of the reasons for moving to later formats such as Spectre, Verilog, and VHDL as netlist formats. The Spectre format should also be considered depricated, leaving Verilog and VHDL as netlist formats. Whether you (collectively) like it or not, this is the industry trend, and gEDA is not in a position to buck the trend, and can benefit by running ahead of everyone else. In conversation last week with the creator of the Spectre format, he commented on why it is the way it is, and why we shouldn't use it, and use Verilog or VHDL format instead. Either of those choices are regular, easy to parse, and provide for named ports that are not order dependent. A netlister needs to work for all symbols. No exceptions. 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. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-08-13
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-08-13.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-08-13-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-08-13-models-jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-08-13-models-ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-08-13-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-08-13-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-08-13.md5sum Changes--- 1. Bug fix in parameter expression evaluation, when functions are called. In the previous version, nested function calls such as exp(abs(a)) were not evaluated correctly. This has been fixed. 2. Parameter functions and measure functions are now separate. In the previous version, they were on the same namespace anticipating future functionality. There was a problem when a measure function (such as the "max" measure) and parameter function (such as "max" selecting the larger argument) were confused. Also .. The web site http://gnucap.org now links to the wiki, which is now the official web site. The wiki: http://wiki.gnucap.org The manual: http://wiki.gnucap.org/dokuwiki/doku.php?id=gnucap:manual === As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: gEDA just hit SlashDotOrg
On Saturday 01 August 2009, Bob Paddock wrote: > http://tech.slashdot.org/story/09/08/01/2114210/Cheap-Cross-P >latform-Electronic-Circuit-Simulation-Software?from=rss > > "Cheap, Cross-Platform Electronic Circuit Simulation > Software? > > dv82 writes "I teach circuits and electronics at the > undergraduate level, and have been using the free student > demo version of OrCad for schematic capture and simulation > because (a) it comes with the textbook and (b) it's powerful > enough for the job. Unfortunately OrCad runs only under > Windows, and students increasingly are switching to Mac (and > some Linux netbooks). Wine and its variants will not run > OrCad, and I don't wish to require students to purchase > Windows and run with a VM. The only production-quality > cross-platform CAD tool I have found so far is McCad, but its > demo version is so limited in total allowed nets that it > can't even run a basic opamp circuit with a realistic 741 > opamp model. gEDA is friendly to everything BUT Windows, and > is nowhere near as refined as OrCad. I would like students to > be able to run the software on their laptops without a > network connection, which eliminates more options. Any > suggestions?"" I was out of town when this hit (which was probably fortunate). What are we going to do about it? If we want people to use our tools .. 1. They need to be the best. 2. We need to provide a migration path -- in and out. Gnucap works fine, but there is a problem with the geda interface. Does anyone want to help? ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Progress with unified build
On Saturday 08 August 2009, igor2 wrote: > National or otherwise local standards. I know someone who > would be really angry at me if I used the --/\/\/-- resistor > symbol instead of the -[]- one, and of course no cad software > can come with symbols for all possible components drawn for > all possible standards. That's like fonts in a text document. Changing to a different standard set of symbols is like changing fonts in a text document. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: KJWave
On Monday 27 July 2009, Daniel B. Thurman wrote: > I have tried using both gnucap and ngspice using KJWaves, > neither seems to be able to find the 1N4004 diode model Google for it. Neither supplies a model library. It's a lot of work to keep it up to date. So, you need to search the web for the model statements. The most obvious answer is "google for 1n4004 spice model". You will find several of them, not all the same. They all should work with either ngspice or gnucap. Since you need to ask, most likely you don't need the detailed model statement. You can probably get away with using the defaults .. .model 1N4004 D If you want something better, but still not all of the details, look at the gnucap manual examples. There is an example showing how to determine IS of a diode experimentally. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: gnucap development snapshot 2009-07-23
There is a new development snapshot available ... http://gnucap.org/devel/gnucap-2009-07-23.tar.gz Optional plugin files: http://gnucap.org/devel/gnucap-2009-07-23-models-bsim.tar.gz http://gnucap.org/devel/gnucap-2009-07-23-models-jspice3-2.5.tar.gz http://gnucap.org/devel/gnucap-2009-07-23-models-ngspice17.tar.gz http://gnucap.org/devel/gnucap-2009-07-23-models-spice3f5.tar.gz http://gnucap.org/devel/gnucap-2009-07-23-tools.tar.gz This file contains the md5sum of the other files, so you can check for a proper download: http://gnucap.org/devel/gnucap-2009-07-23.md5sum Changes--- 1. Holger Vogt's mods for MS-Windows. You still need to edit the "Make2" files, but that should be easy. 2. Other minor changes in spice-wrapper. 3. Change result of cross, min, max measures when the event doesn't happen and looking for "last" event. It now returns -infinity. Previously it returned +infinity. A first event never happening still returns +infinity. Most recent work has been in documentation and testing. The main web site now uses the wiki. The manual on the wiki is nearing completion, so use it in preference to the old manual. The wiki: http://wiki.gnucap.org The manual: http://wiki.gnucap.org/dokuwiki/doku.php?id=gnucap:manual === As usual, to get started you need only the main package gnucap-2009-xx-xx.tar.gz . ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Learning Spice: TwoStageAmp example
On Thursday 23 July 2009, Daniel B. Thurman wrote: > al davis wrote: > > On Monday 20 July 2009, Daniel B. Thurman wrote: > >> Also, I would appreciate it if someone could point > >> me to a tutorial or sample project that shows how > >> one can do spice simulation! > > > > Did you look at what Stefan suggested for Gnucap? > > Yes, I did > > >>> Very basic: > >>> http://www.johannes-bauer.com/electronics/ > > I have gotten all the way though to the point of trying > to display the curves with `gwave'. The problem is with > Fedora's 9/10/11 gwave builds, or so I think. > > It seems there is a problem with gwave builds on Fedora. > (crash) > > I reported this problem on the Fedora-Users mailing list and > so far no response. It works for me on Debian, without crashing. I wouldn't expect a response on the Fedora-Users list, but you should be able to get help here. I believe Chitlesh Goorah maintains the Fedora package for gwave. He monitors this list. Chitlesh, can you help??? Usually I run gwave from the gnucap prompt ... gnucap> tran 0 1u .01u trace all >z gnucap> !gwave z & ! says run a shell command, & says to detach like the shell does. > I tried to build gwave from sources but > there was a problem in which make was failing to locate > gnome2 modules, so I gave up. There is a library you need that is not installed. I don't know what they are called in Fedora, so I can't tell you which one. You need the "dev" versions of the libraries, which are not installed by default. Does the configure output give you any clues? It doesn't work very well. > I also downloaded the ngspice source, did a build, and all > compiled with success, but issuing a `make check' revealed > that the tests fail short starting with the bipolar models > and quits where there are many more tests to go. You need to ask the ngspice people about this. I do know that there is a difference in math functions between AMD-64 and Intel processors, so the results could be a little different. The differences are not significant, but could cause tests to fail if they are based on text file comparisons. > For some reason, it seems I cannot get a simulation to work > with the gEDA tools and I thought I was doing something very > wrong, and that is why I was asking for a tutorial > explaining, step-by-step, so as to demonstrate that the these > tools actually work. So far, it has not, with the tutorials > I have been working with. I don't use gspiceui .. It just goes against the way I want to work. Usually, I run gnucap interactively, from the command line. The netlister isn't perfect. You should use the "spice- sdb" netlister, not plain spice. Even so, often I need to manually edit the netlist to make it work. Working with files as I usually do, I can deal with it. With a GUI, the slightest imperfection makes the whole thing useless. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
