It's not as bad as it looks. In a development snapshot, sometimes there are warnings for things that would be suppressed later.
I do not have your models, so I am guessing here. On Monday 03 December 2007, a r wrote: > Now, how to use the models? > > I have attached the bsim330.so and got a message: > > M: already installed, replacing > stashing as M:0 That is telling you that the attachment is hiding an internal model. That's what you want, isn't it? > When I use MOSIS models (level=49) directly I get error: > > Mp.xi1: model cmosp is not a bsim330,bsim3 > > When I change level from 49 to 8 the simulation _works_ but I > get some errors/warnings: Expected .... That model installs as level 8. I suppose it should also work as 49. That's easy. > > LEVEL = 8 VERSION > ^ ? bad parameter, ignored That is probably a bug. I need to see the ".model". > > and then bunch of warnings: > > Warning: This model is BSIM3v3.3.0; you specified a wrong > version number. What version did you specify? Maybe you don't want 330 .. There is probably something like "version = xxxxx" in the .model statement. What does it say? You should use the model that matches. The handling of this not quite correct now. It will get better. This is one of the reasons it is still a "development" version. > Warning: Pd = 0 is less than W. > Warning: Ps = 0 is less than W. You didn't specify pd, ps. Spice would give you the same warning. This is printed by the BSIM code. It probably should not be printed this way, but I didn't write it. It is a bad idea to leave "printf" statements inside of model evaluation code. I don't know what to do about it, other than modifying code in violation of a policy not to modify. All I can think of is a header that #defines printf to nothing. Recall... the Spice model code is used without any modifications. > [...] > initial step rejected:Mp.xi1 > new=1.87716e-12 old=1e-11 required=5e-12 This is telling you that the stepping you requested is too large, enough too large that you should know about it. Even if the simulation is correct, you are not seeing all that is happening. > storage element step control error:Mp.xi1 6.11037e-17 > using Euler, disabling time step control There is a tiny capacitor that probably can be ignored. Gnucap has decided to use "euler" for that one. The message should be reworded ... Time step control and Euler only apply to that element. The rest of the circuit is still using full step control and the method you requested. It is probably working correctly, just letting you know that you are missing something. On these last two .... some other simulators take similar action and don't tell you. It is my opinion that the worst thing a simulator can do is to hide when it believes the answers might be off, leading you to trust data that you shouldn't. The worst of that is when the wrong results are believable. You say it works .... No trap ringing??? It looks like it found where the trap ringing is coming from. The print resolution you asked for is too coarse to show the effect of it, so it switched to Euler and assumed you don't care to see the effect of that part of the circuit accurately. Consider this RC network ... v1 1 0 pulse (....) r1 1 2 1 c1 2 0 1f r2 2 3 100k c2 3 0 .001 The time constant r1 c1 is 1 femtosecond. The time constant r2 c2 is 100 seconds. If you do r1 c1 with trap, it will ring badly, or do really tiny steps. Solution: use Euler, ignore step control. That lets the other (r2 c2) control the stepping, and hopefully you get the results you want. If you specify time stepping appropriate for r1 c1, The step control will catch it, and give you correct results for that. You may think this is a bogus situation, but it isn't. In a real circuit, the fast TC probably comes from strays, like the internal capacitance of a device. The slow TC is probably what you want to build, some kind of filter. You might want one or the other. It can tell by the stepping and range you ask for. My circuit design experience includes wideband amplifiers, where this matters. You see it in audio. You see it more in video. _______________________________________________ Help-gnucap mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnucap
