On Thursday 05 April 2007 10:19, John Doty wrote: > It really needs to be built into the device models. Much of > the point of a SPICE NOISE analysis is to be sure you haven't > left out an important noise source in your pencil and paper > noise analysis.
Verilog-AMS supports that, so eventually gnucap will have it. Whether it is built into any particular model depends on whoever wrote the model. Gnucap models need not be specific to gnucap. There will be several mechanisms for using different kinds of models, including spice C models and Verilog-AMS. Eventually there will be more depending on demand and resources. They are all plugins, and all look the same to the core. Well ... they will have wrappers that make them all look the same to the core. I expect that Verilog-AMS models will be more efficient than Spice models. Most likely they will have identical user interfaces. Most new models are coming out in Verilog-AMS, not Spice, particularly the detailed ones with noise. > Of course, explicit noisy sources could be handy too, for > noisy inputs, power supplies, etc. It's really the same, because it is defined in Verilog-AMS. I was describing what you can do in gnucap now. > In the tricky cases it's not a simple matter of display. The > simulator output needs a fair amount of post processing. > Tools like AWK, C, and Mathematica come in handy, here. There is a real need for a good postprocessor. I expect to see some improvements to the ones we have soon, but it will be a while longer until we see a real postprocessor program. Ideally, the whole thing would be written in an interpreted language that lets you bring out the interpreter so you can write your own manipulations. Python, Ruby, TCL-TK, R .. are all possibilities. Probably the best choice of these is Python, because there are libraries available for most of what is needed. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user