On Wednesday 04 March 2009, r wrote: > On Wed, Mar 4, 2009 at 7:07 AM, al davis <ad...@freeelectron.net> wrote: > >> like it, for example, I put m=50 to report the full > >> current instead of 1/50 of the current going into it. > > > > The Gnucap behavior is consistent with Hspice and Spectre. > > At least that is what I have been told. I don't have > > access to them to check it out. > > That's incorrect. Both Spectre and Hspice treat devices with > m>1 as single entities.
ok .... maybe you can help solve this. I'm dealing with a policy that requires that unmodified models designed for other simulators, including unmodified spice models, can be used as plugins. For example, the BSIM models from Berkeley. It's my understanding that when you specify (for example) BSIM430, that means you want BSIM430, whatever that is, not BSIM440 or anything else. Also, when a new one comes out, it should be able to be used as is, so you can have it right away. Those models do not support the "m" parameter as supplied. Now, also consider subcircuits .. Specify "m=" when you instantiate a subckt .. that propagates down to everything under it. No exceptions. If a device inside also specified "m", it's not an override, but a multiplier. Also consider that there are a bunch of parameters that can be probed. Some multiply, some divide, some are not changed. There is no indication in the code of which is which. There could be hundreds of parameters that could be probed. All that is known is a name and the type (real, int, string, ....) that it returns. There is no notion of across, through, or anything that helps the decision of how to scale. The only method I can think of is to add another section to the "wrapper.h" file, where you can arbitrarily define new probes (already on the to-do list), or a table where you can list the probes and mark how they are scaled. Even that is not a full solution, because it only applies to models that use wrapper.h and spice-wrapper.cc. Still, this is a manual operation, something that may not always be done. If you have any better ideas, please tell me. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user